CodeParkFor a typical backend service, the trophy or honeycomb shape fits best: make integration tests the biggest layer.
The test pyramid says:
- write many unit tests
- write fewer integration tests
- write very few end-to-end tests
The reason: tests get more costly, slower and more flaky (pass or fail at random) as you go up the pyramid.
The testing trophy (from Kent C. Dodds) makes integration tests the widest layer. It sits on top of static analysis: checks that run without executing code, such as TypeScript and linting.
The honeycomb (from Spotify) says the same thing for microservices. Most of a service's code is glue between HTTP, a database and other services. So the most valuable tests run the service against real dependencies and check behaviour at its edges. It uses few unit tests that check implementation details.
Most Nest services mainly create, read, update and delete records (CRUD). For them, integration tests against a real Postgres usually give the most confidence per test. Keep unit tests for really complex domain logic, and keep e2e tests few.
In short: these shapes are rules of thumb, not laws. The goal is fast feedback plus confidence that the service works.
- The pyramid means many unit tests, fewer integration tests and very few e2e tests.
- In the trophy and the honeycomb, integration tests are the widest layer.
- Services are mostly glue code, so testing their edges with real dependencies pays off.
- Unit tests still fit complex domain logic.