Why should I write unit tests if I already have E2E tests [closed]

Question

If we're already doing E2E (end-to-end) testing do we also need to write unit tests?

Considering we are doing all functional testing in end-to-end testing, what are the pros and cons of doing both?

Answer 1

Because E2E tests are not a perfect substitution for unit tests.

\> Update 2025
\> My opinion: Write some unit tests. Pay good attention to integration tests.

They are slow to run

Ok these reasons sound silly if you don't do regular automated testing but unit-testing (In fact any type of extraneous code) is actually a social problem more than a technical one.

Simply put:

• If it pisses you (or any stakeholder involved), even a little bit, you''ll drop it.

• If it doesn't provide a "i cant live without it" feeling, you'll drop it.

It's non-core code so it's the first victim to a frustration. So it has to be ergonomic to survive. Writing useful tests that stick along for the ride is much harder than it initially looks.

A fast but non-comprehensive test suite is actually okay (or even preferred) but a comprehensive but slow one, is gonna be a goner very soon.

The cycle you want in uni-testing is:

do a change --> run suite -> do another change ---> run suite

The fun in unit-testing is just that; it' builds a guardrail that helps you stay focused and carefree more or less. A test suite that needs 5 seconds to run is gonna have me distracted and losing focus. An e2e suite can take hours to complete.

E2E tests span (and actually use) actual services, not mocks. Unit-tests, ideally, are isolated to units-of-works on the same layer: in-memory.

If I have to wait a long time for a test run to end, I'm probably also gonna start skipping it more often.

They don't isolate failure

E2E tests tell you that a whole scenario is broken, i.e 'User login faled'. They don't tell you which part of which component that takes part in that scenario is broken. This makes it harder to tell which part of the code caused the test failure.

They hurt reusability

You can't plug-out a component of your system and drop it in another system with confidence. There's no unit-tests to run for that component, in the new environment.

You can't do per-unit TDD

If you want to carve out a new component(unit) for your system and use TDD while you're at it, you're at a dead-end without unit tests. Unit tests and TDD go hand-in-hand.

---

That being said:

• Having both E2E tests and unit-tests is what you should be aiming for, if your resources allow it.
• Having only E2E tests is always better than having no tests at all.

Here's a nice illustration of the perfect test-suite, called the Testing Pyramid:

This article from the Google Test Blog goes into more detail: Just Say No to More End-to-End Tests. While I don't agree that you shouldn't write E2E tests, it illustrates the pros and cons of each, in-depth.