Key takeaways
- E2E tests earn their cost only on the journeys that make money; everything else belongs lower in the pyramid.
- Brittleness comes from locators and timing, so use stable test hooks and explicit waits.
- A suite people rerun until it passes is not a safety net, so fix flakiness rather than retrying.
LoadFocus – is a easy to use cloud testing tool, and you don’t need any setup, it runs from the browser. It helps you understand better your Website’s and WebServices’ performance and find potential bottleneck before your customers do. Run a free website speed test today.
Is Your Infrastructure Ready for Global Traffic Spikes?
Unexpected load surges can disrupt your services. With LoadFocus’s cutting-edge Load Testing solutions, simulate real-world traffic from multiple global locations in a single test. Our advanced engine dynamically upscales and downscales virtual users in real time, delivering comprehensive reports that empower you to identify and resolve performance bottlenecks before they affect your users.
Writing UI tests that are resilient and easy maintainable is hard. Everyone knows that UI tests are slow and flaky but using a few best practices can make the job of implementing and maintaining UI tests a little more easier.
Here are some best practices that we found useful:
- use the page object model/robot pattern; this makes the tests easier to understand and update
- make the tests run independently from one another and still pass; not fulfilling this will make your tests flaky and give weird behaviours on different environments
- use data-*(data-test/data-testid) attributes so that we can keep the tests independent from the changes in the CSS or JS (ex. button id=”main” class=”btn btn-large” data-test=”submit-login-btn”); this will make your tests more resilient to changes in CSS or JS
- use more assertions in a single test as the framework should give you enough information related to which check failed; also UI tests take a long time to go to a page so it’s preferable to have more assertions on that page; this will take the number of tests lower and a side effect will also be the running time of the tests will go down
- clean up the state before each test run and at the end of the test using beforeEach / afterEach; this will improve reliability and make the tests less flaky
- do not use wait for arbitrary periods of time; instead use assertions that wait for a specific condition to be met; this will make the tests less flaky and avoids weird fails in the tests
- always set the start url in the context of your test; do not set as start url that needs an entire flow to be run so that we get to what we want to test; this will lower the execution time of the test suites and avoid fails triggered by bugs in different parts of the application which are not to be tested by the respective test suite
- talk to 3rd party services via their API not by visiting another web app; this will decrease flakiness of the tests and lower the execution time of the test suites
LoadFocus – is a easy to use cloud testing tool, and you don’t need any setup, it runs from the browser. It helps you understand better your Website’s and WebServices’ performance and find potential bottleneck before your customers do. Run a free website speed test today.
Frequently Asked Questions
How many end-to-end tests should a project have?
Far fewer than unit or integration tests. E2E tests are the slowest and most fragile layer, so they earn their cost only on the journeys that make money: signup, checkout, login. Everything else is cheaper to cover lower down the pyramid.
Think your website can handle a traffic spike?
Fair enough, but why leave it to chance? Uncover your website’s true limits with LoadFocus’s cloud-based Load Testing for Web Apps, Websites, and APIs. Avoid the risk of costly downtimes and missed opportunities—find out before your users do!
Why are my UI tests flaky?
Almost always locators or timing. Locators tied to CSS classes or DOM position break the moment someone restyles the page, and implicit sleeps either waste time or fire too early. Use dedicated test attributes such as data-testid, and wait for a condition rather than a duration.
Should tests share state to run faster?
No. Each test should set up what it needs and pass on its own, in any order. Shared state is what produces suites that pass locally and fail on CI, and it makes a single failure impossible to read.