DEV Community

Cover image for The testing pyramid is outdated! E2E tests are now easy to write
Giorgio Boa
Giorgio Boa

Posted on • Updated on


The testing pyramid is outdated! E2E tests are now easy to write

No doubt having a well-tested code base allows us to cover regression errors during releases.

Unit test

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.

Cypress configuration


Trigger 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.

Final thought

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 ❤️.
Bye 👋

Latest comments (3)

tinydevops profile image
Jonathan Hall

Another perspective for consideration:

latobibor profile image
András Tóth • Edited

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:

  1. An e2e test tests literally everything. I was tearing my hair out once over timeout tests failing - as it turned out the time on the virtual machine was off due to a bug. This means you are going to test the OS with the e2e test as well. You are also going to test the compatibility of Chrome drivers vs. latest Chrome releases and so on.
  2. Because of #1 when an e2e test fails the scope of your debugging will be huge. With unit tests you know that it must be the unit that fails. With integration tests you can be sure that the error is coming from those parts. I would say it is very easy and great to drive out all edge-cases in unit tests, then you know they work and other layers need not to check all of them.
  3. In reality e2e tests are really hard to maintain: people make changes often, UI/UX changes, backend timing issues can happen (some services get slower, or order of things appearing change), sloppily written modules mess with the order of UI elements appearing etc. I remember we had 4 teams working on unit + e2e tests and the limit was around a 100 e2e tests maintained (with about 5-10 of them permanently temporarily commented out because they were flaky).
  4. Who's time is to investigate the error? When we had this setup of unit tests + ~100 e2e tests I 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.

gioboa profile image
Giorgio Boa

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.

The most important JavaScript discussions happen on DEV

React vs Signals: 10 Years Later

React vs Signals: A Look Back

☝️ Ryan Carniato and Dan Abramov take a look back at React!