The pyramid, and a unit test in isolation

Shape your tests like a pyramid, not an ice-cream cone

You've built the whole PawWalk backend — walkers, bookings, auth, a job queue. Now you have to trust it under change. The senior move is deciding where to spend test effort, because not all tests cost the same. The test pyramid is the standard answer: a wide base of unit tests (many, fast, no I/O), a thinner middle of integration tests (a few real wirings — a service plus its database), and a tiny cap of end-to-end tests (fewest, slowest, boot the whole app).

• Unit — one class, its dependencies mocked. Milliseconds each. Run thousands on every save.
• Integration — a couple of real pieces together (a service against a test database).
• E2E — a real HTTP request through the whole Nest app, top to bottom.

The senior pitch: Fast tests you run constantly catch bugs while the code is still in your head; slow ones you run rarely catch them after you've moved on. I invest at the base of the pyramid so the feedback loop stays tight.