The Three Sizes

Unit. One function or class, nothing else. Milliseconds. Tells you exactly what broke, and tells you nothing about whether the pieces fit together.

Integration. Several parts together: a view with a database, an API endpoint with its serializer. Slower, and it catches the mistakes that live between components, which is where most real bugs live.

End to end. The whole system through the interface, as a person would use it. Slowest by far, catches things nothing else can, and is the most likely to be flaky.

How many of each. Many unit tests, fewer integration tests, very few end to end. That shape is usually drawn as a pyramid, and the reason is cost: a unit test costs milliseconds to run and minutes to write, an end to end test costs seconds to run and hours to maintain.

The common failure is an inverted pyramid: a large end to end suite that takes forty minutes, fails randomly twice a week, and that everybody has learned to re-run rather than investigate. At that point it has stopped being a test suite and become a delay.

✦ For a full stack project, integration tests earn their keep most

A view with a real test database catches the wrong query, the missing permission check, the serializer that omits a field, and the URL that does not resolve, all in one test that takes a few hundred milliseconds. That is the best ratio of bugs caught to time spent in this kind of application.