The test pyramid
The three test levels, from the unit test to the end-to-end test, the pyramid shape that spreads their number, their duration and the precision of their diagnosis, and the ice cream cone to avoid.
- 23 cards
- 5 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- On the timeline
- Scenarios
A few cards from the deck
Unit test: what is it?
Show the answer
A test that checks one small unit of code (a function, a method, a class) isolated from the rest of the application.
With no database, no network and no interface, it runs in a few milliseconds; when it fails, the fault is in the unit under test.
Why is the number of end-to-end tests kept low?
- Slow and fragile, they point poorly at the fault when they fail
- They do not check what the user sees, only the internal code
- They redo what the unit tests already check and find nothing more
- They cannot be automated and must always be run by hand
Show the answer
Slow and fragile, they point poorly at the fault when they fail
An end-to-end test does check what the user sees, it can be automated (a driven browser) and it finds faults no unit test sees, such as a journey broken between two screens. Its flaw is the cost: slowness, flakiness, a blurry diagnosis. So you keep a few, on the essential journeys.
In the test pyramid, the … holds the unit tests, the most numerous, and the … the end-to-end tests, the least numerous.
Show the answer
In the test pyramid, the base holds the unit tests, the most numerous, and the top the end-to-end tests, the least numerous.
Tests at the base cost little to write, run and maintain: you can have thousands. Those at the top are expensive: keep them for the essential journeys.
Integration test: what is it?
Show the answer
A test that checks that several modules, or a module and a real resource such as a database, work together.
It finds the faults unit tests cannot see, those of the interfaces: wrong format, wrong unit, misnamed column. It is slower, because it runs real components.
A suite has 40 unit tests and 600 end-to-end tests. It takes 2 hours and fails at random. What is the main cause?
- An inverted pyramid: most of it rests on slow, fragile tests
- The unit tests are too many and slow down the end-to-end tests
- The continuous integration server is undersized: a more powerful machine would fix everything
- The end-to-end tests are not numerous enough to cover the application
Show the answer
An inverted pyramid: most of it rests on slow, fragile tests
Six hundred tests driving the browser, the database and the network take long and fail depending on waits and data state. A more powerful machine would shorten the run a little, but not the random failures: the problem is the shape of the suite.