Until recently my team used selenium automation tool for E2E testing. It worked as expected, but team work-flow started regressing with time.
- selenium based test automation tool is implementation sensitive
- it’s stored in the separate repo, which affects CI flow
- more and more flaky tests started to come with time
- python is not a commonly-known language across our team
Considering above an opportunity to try out different tool presented itself, so we decided to give Cypress a try.
Main motivations for switching to Cypress
With Cypress, technology stack is more coherent across the fronted team, as pretty much everyone knows Typescript,
npm
etc. This makes writing tests more group oriented, instead of putting the whole burden on QA team.
A big selling point is a similar syntax between unit
and E2E tests due to using testing-library
The more your tests resemble the way your software is used, the more confidence they can give you. Kent C. Dodds
No more cumbersome async handling and waiting for resolved state, as cypress deals with such cases out of the box.
Overall code quality should improve, as testable code most of the time requires improved design and interfaces. Also, accessibility features will be required in order for querying elements resembling user behaviour.
Monorepo for frontend code and E2E code makes implementing test related changes way more accessible. This will allow quick changes to refactor hard to test code bites.
E2E tests could be used as documentation of business requirements in form of user stories.
Now it will be possible to automate E2E testing within CI, so we will benefit from fail fast principle.
In future posts I will share my thoughts with hands-on experience with our new automation tool of choice.