Best Practices for Writing and Running End-to-End Tests

Contents

Introduction

When writing new tests for an automated end-to-end test suite, there are a few essential principles to keep in mind. Establishing these as good habits from the beginning will help you avoid disruptive issues down the road requiring changes that cost you a lot of time and stress.

Here are some essential and good habits to follow when making both tests and the entire test suite:

Stick to the perspective of end-users

When you start writing the first tests, it’s important to think like an end-user. Put yourself in their position and think about what the merchant or customer is trying to achieve.

  • What are the features of your application that they want to use first?
  • What he/she wants to use the most?
  • What is the purpose of using the product?
  • Can the user accomplish their goal in a few easy steps?

Place the tests in the appropriate order

When tests stop working, it is easier to find the problem, and it is easier to fix and improve the test if you set them in the correct order. It is up to you to determine the proper test order knowing your product’s actions depending on what the user first sees when entering the product and the last step they need to take.

Make the tests more concise

Don’t pile up scenarios in one test a lot. It’s always better to have multiple test files rather than one test file with numerous scenarios in it. The test case itself should be as simple as possible and written to include everything essential for testing the functionality in it.

Include your own automation IDs

To avoid maintaining selectors in the future, it’s always a good idea to include your own data selector, such as test-automation-id, while automating browsing, instead of generally searching for visible elements on the page and using their IDs, classes, and XPaths. It’s totally fine to constantly use automation ID pickers in your automation tests. Better is to stick with your static selectors than to depend on changes in the future.

Don’t ignore flaky tests. React as soon as possible.

When you discover that a test is flaky, you should react as soon as possible; if you allow yourself to ignore flaky tests, things can only worsen. Likewise, when you write tests, it’s also helpful to consider how and where they might be flaky. You can add additional code that will slow down the test a bit or make it more solid, which will help insulate your tests from the possibility of flakiness, even if there are slight changes in the product itself.
Hint: What is a flaky test? Test that sometimes fails, but if you do retry enough times, it eventually passes. It’s not a bug, you just need to make a better test.

Tests should be self-contained

Each test should first create its environment before executing and, if possible, clear the data at the end or leave it but never use it in other tests. Test independence is essential for the accuracy of the test execution and for ensuring a non-flaky environment.
It is worth knowing that independent tests are often called “atomic” — which is derived from the Greek atomos, meaning “uncuttable.” Basically, the idea is to make every test self-contained.

Use helpers and tools

If you see something you write twice, automate it in a helper or page utility. It is preferable to have methods that you will use more than once than it is to write the same code twice. Don’t worry if the execution of your tests goes a lot through other places outside the test case itself. Focus on keeping your code neat and readable, and let the functions be performed in helpers and page utilities if necessary.

Separate back-end and front-end flows

It is good to separate those helpers and utilities that refer to backend tests and frontend tests. By backend, we mean all those configuration settings in the WP Admin section to be stored on the backend.openDashboard(); for example, and the frontend, you have stored on the frontend.openMyAccount();. This behavior will make it easier for you to write new tests and maintain the entire test suite.

End-to-end Testing Packages

These are just some of the essential tips to follow if you want your test suite to contain clean, robust code that is easier to maintain. Below you’ll find the links to various packages to help you implement end-to-end testing in your WooCommerce extension, including a boilerplate project that you can use as a springboard to build out your own test suite.

Required packages

  • NPM v6 — This version of NPM is currently required for setting up subsequent dependencies.
  • WooCommerce E2E Environment – This package consists of a basic Docker container and scripts for running tests.
  • WooCommerce E2E Utils – This package includes a variety of functions to simplify writing tests.
  • WooCommerce API – This is a utility package for accessing the WooCommerce REST API.
  • Jest – A npm package for running tests.

Optional Packages

←

Back: Unit Testing

→

Next: Setting up Linting