No doubt having a well-tested code base allows us to cover regression errors during releases.
Often we just test the business logic with unit tests, because they have a smaller scope and a very high execution speed.
These tests are a fair compromise between the effort spent and the benefits we get with a well-tested code base.
There are also other types of tests such as End-to-End ones, they are more demanding and time-consuming to write and require more execution time.
Until recently, I was also on the same line of thinking until I tried to use ... Cypress.
It is an automatic tool and allows us to write and execute E2E tests quickly and easily.
Wow, this is awesome, but there is more...
Now with Cypress Studio, you can record tests quickly and easily instead of writing them.
But how can I register for my test
Once Cypress has been installed a "trigger" test and the experimentalStudio property in the cypress configuration will be sufficient to start recording your first test.
Now you can start Cypress Studio and record new tests like this example:
✅ In the docs you can the official example and all the steps to use it.
Recently I introduced this functionality in a project that we wanted to cover with the E2E test.
Together with the users of the platform we recorded the core flows of the application.
The results are excellent, with a little effort we were able to strengthen our tests and now we can sleep more peacefully.
You can follow me on Twitter, where I'm posting or retweeting interesting articles.
I hope you enjoyed this article, don't forget to give ❤️.
Oldest comments (3)
I have extensive test automation background (I did that for 3 years professionally) and I disagree with you.
I am giving a couple of facts that might change your mind:
unit tests + ~100 e2e testsI remember having to fire up the system, trying to see what's going on, where does it fail, then trying to debug it on the frontend and then realizing "Oh, shit, it's the backend!". That already wasted a ton of time. If you have API tests those can tell you right away where to first check.
So in reality layers save time for you.
I think your vision well describes the problems that can occur in a large project and I usually work in micro-teams with a medium code base.
The context is certainly different however thanks for your feedback because you exposed real problems with the e2e tests.
Another perspective for consideration: youtube.com/watch?v=QFCHSEHgqFE