34
How much flakiness do you tolerate in end to end tests?
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Aug 2023
34 points (100.0% liked)
Experienced Devs
3956 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
I'm a fan of randomizing the test order. That helps catch ordering issues early.
Also, it's usually valuable to have E2E tests all be as completely independent as possible so it's impossible for one to affect another. Have each one spin up the whole system, even though it takes longer. Use more parallelism, use dozens of VMs each running a fraction of the tests rather than trying to get the sequential time down.
The problem with randomising the test order is that it compromises the reproducibility of results. If there are ordering issues, then your tests will sometimes fail and sometimes pass, but will developers look at that and think "ah there must be an ordering issue" or will they think "damn these flaky tests, guess I'd better rerun the pipeline"?
Wherever possible, this is a good idea. The campsite rule - tests don't touch data they didn't bring with them - helps as well.
However, many end to end tests exist as a pipeline, especially for entities that are core to the business function of the app. Cramming all sequentiality into single tests will give you all the problems described, but in a giant single test that you need to fish out the result for.