e2e Testing Playwright

10 tips for successful e2e web app test automation

  1. Write independent automated tests: you should try remove dependencies on other tests or test data – this allows tests to be consistent, repeatable and to run in parallel (see #6).
  2. Set up data/state for each test via API calls: calling APIs is quick and efficient and can set up exactly what you need.
  3. Clean up data/state for each test using “after” hooks: this ensures test environments are kept clean and tidy and unwanted test data doesn’t cause issues with exploratory testing.
  4. Re-use browser authentication so you only need to log in once: this speeds up tests, see this post on how to do this with Playwright.
  5. Generate and use consistent (static) test data for each test: only generate unique/randomised values to satisfy uniqueness constraints, else use hard-coded known good values. Further reading here.
  6. Run all tests in parallel locally and in CI: hardware is powerful and there’s really no reason not to (unless you use Cypress and can’t 😝)
  7. Run new/updated tests at least 10 times locally in parallel before committing: this helps with reducing and removing non-deterministic tests and race conditions from your test suite.
  8. Use your automated test scripts to assist with manual/exploratory testing: for example you can easily set up state/accounts/sessions for testing – create npm commands so you can run npm run newuser for example to generate and log in as a brand new user ready for testing.
  9. Use linting/code autoformatting: such as JavaScript Standard Style, for consistently formatted code and not having to make decisions.
  10. Focus on reducing the need for manual regression testing, rather than code coverage: when you can confidently release your web application with no manual regression testing you know you have enough e2e automated tests.

What are your tips for successful web app test automation?

3 replies on “10 tips for successful e2e web app test automation”

Minor suggestion: if you do your cleanup in the beforeEach rather than the afterEach, then retries will succeed even if the test suite completely bombs out. It also means that the db state is persisted in the event of failures so you can more easily investigate what happened.

Hi Alister,

Point #2, found it difficult to do with legacy as it resulted in incorrect data and therefore invalid testing.

Super sweet that you can use it tho, will give it a shot, thx for the tip! =)


Great list, I agree on #2 legacy systems without API interfaces, makes it really hard. one approach I’ve taken is to build my own api in some scenarios, where I write directly to the database. It’s big up front cost, but if there are no plans to add API endpoints to expose the logic, and the system isn’t changing much, it’s been a great decision.

I agree on #5 using static data is a must on some scenarios.

One thing I that is worth adding is create your checks in a way that allow you to point your tests and different environments. This allows the devs to run regression tests against brand new builds and get feedback as soon as a site is built.

Leave a Reply

Your email address will not be published. Required fields are marked *