Disclaimer:
My opinion is heavily influenced by the type of software I have worked on in my career: mostly full-stack web and mobile applications. If you build a different kind of software, you may reasonably come to the opposite conclusion.Also, "the terms 'unit test' and 'integration test' have always been rather murky, even by the slippery standards of most software terminology".
I won't attempt a definition here. I'll go with what I have experienced as a software developer.There is no silver bullet that applies to all types of software. Do what works. Do what you feel is right.
With the disclaimers out of the way, here comes the hot take:
I do not care about unit tests. There. I said it.
I couldn't even care about unit tests if I wanted to.
I don't care because they don't do what tests should do: verify that the application I am working on works as expected.
But before I get into why, some context.
The History
Every developer has seen a version of this image:
I don't know who came up with this pyramid, but it's fair to say it is now part of software development culture.
The idea behind it is perfectly sound. It's all based on how cheap (aka how fast to write and execute) these individual layers are:
- Unit tests are cheap, so let's write a lot of them.
- Integration tests cost more, so let's write fewer.
- E2E tests are 'expensive' and sometimes brittle, so let's write even less of those.
The Problem
Here is my personal beef with unit tests: they don't give me confidence that my application works as expected.
They are too isolated to prove anything.
A test that examines one component alone cannot prove that multiple components work together in reality.
A good example of this is the Mars Climate Orbiter.
In 1999, NASA lost this bad boy during its entry into Martian orbit because two systems worked together in unexpected ways.
- Unit A: A ground software that reported thruster force output correctly using imperial units.
- Unit B: A navigation software that processed trajectory updates, assuming the data from Unit A was in metric units.
Write a unit test for either one and it passes.
The orbiter entered the atmosphere 170 kilometers too low and was never heard from again.
This mistake cost NASA a $327 million mission (~$655 million in today's money).
Proving that unit tests don't catch bugs like this: Priceless.
(Yes, the real issue was the contract between the two units. But the only test that catches a broken contract is one that runs both sides of it.)
Each component did exactly what its own tests would check for. The ground software calculated the right forces — in the wrong units. The flight software trusted the numbers it was given.
The failure lived entirely in the gap between two components that each worked fine.
It's the perfect example because it shows where bugs live: rarely in single components, often at the intersections between them.
Here is a quote from the official investigation into this tiny mishap:
"End-to-end testing to validate the small forces ground software performance and its applicability to the specification did not appear to be accomplished."
— Mars Climate Orbiter Mishap Investigation Board, Phase I Report, 1999
How AI Changes Things
AI changed software development, so we need to re-evaluate our accepted 'truths'.
One reason E2E tests used to be expensive was the slow feedback cycle. A unit test runs in milliseconds; an E2E test can take minutes.
This is a problem for a human developer, who has to wait for each run to finish before adjusting the test and starting again.
The gap between runs is usually too short to do any meaningful work, so developers end up waiting idly.
With AI agents this problem is less severe: I can ask an agent to run the tests and fix them while I work on some other task.
At the end, I verify the solution.
This means the cost of writing E2E and integration tests has come down significantly.
But here's the catch: AI didn't just make tests cheaper to write. It made bad tests cheaper to write too.
An AI agent will happily create thousands of unit tests, with mocks decoupled from reality and assertions that don't matter.
The Fix
So the question I have to ask myself is: which tests give me the highest confidence that my application works as expected?
Do those thousand green tests the AI agent wrote in an afternoon give me much confidence? No.
So let's focus on the other types of tests we have at our disposal:
- Integration tests
- E2E tests
Both have their strengths and weaknesses:
E2E tests are the closest to reality, but they're slow and the most brittle. Integration tests give up a little realism in exchange for speed and stability.
That trade is why, in my opinion, integration tests offer the greatest return on investment — and why I prefer the 'diamond' to the 'pyramid'.
Meaning: focus on integration tests. Add some E2E tests to cover the most-used flows, and some unit tests — but not too many.
For modern web and mobile applications (think Gmail, Figma, Trello), there is no way around E2E tests.
They exercise the whole system, from UI to backend, in a single test. I have found them to be the best at finding actual bugs.
And it's not hard to imagine why: the closer a test is to reality, the more confidence it gives us.
So next time you're about to write a unit test, ask what would give you more confidence — that test, or an integration test one level up.
In the AI age, the cost difference is almost gone. The confidence difference remains.
AI Disclosure
I used AI (Claude) to fix my embarrassingly numerous spelling and grammar mistakes. I also used Claude Code's /deep-research skill to find sources that confirmed what I already believed, which is something you shouldn't do — but oh well.
Top comments (0)