At my company there has been a move away from our large e2e testing suite for various reasons:
flaky tests
long build times
significant burden for multiple teams to contribute
The use of pact is seemingly only covering some small portion of each integration point between applications as large, comprehensive pacts that cover the full API and values used are considered too costly or coupled.
I am conflicted that we are losing test coverage of business use cases because there aren’t necessarily any tests that are automatically running a use case end to end.
How do you deal with this in your workplace and what is your position on e2e vs pact testing.
We found that flakiness of e2e tests is usually caused by using libraries, frameworks and devops tools that were not designed for being integrated in e2e tests. So we try to get rid of them, or at least wrap them with devops magic. This requires a skilled devops team and buy-in from management.
At some point we were also solving the issue by having dedicated human reviews of e2e failures, it’s easy to train a junior QA engineer to have most false positives quickly retried.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@beehaw.org
All things programming and coding related. Subcommunity of Technology.
We found that flakiness of e2e tests is usually caused by using libraries, frameworks and devops tools that were not designed for being integrated in e2e tests. So we try to get rid of them, or at least wrap them with devops magic. This requires a skilled devops team and buy-in from management.
At some point we were also solving the issue by having dedicated human reviews of e2e failures, it’s easy to train a junior QA engineer to have most false positives quickly retried.
But we would never give up on e2e.