[bcoughlan]

Overly granular tests are a scourge of our industry, unless you’re writing a widely used utility library. It leads to tests that become a useless burden for even mild refactoring.

Writing larger test cases that test the actual functionality is a game changer. With Testcontainers and good mocking tools you can spin up a real version of your app with external dependencies mocked and faked, and write test cases against the same input layer your user uses. If your test fails you can be pretty sure it’s because you broke something.

This is a layer between unit and integration tests that you don’t read much about. I call them “service tests” (coming from a microservices world).

Investment is still needed though to reduce the effort of implementing tests, like extracting common fixture code so that every test doesn’t need long winded setup code. Also snapshot testing libraries take the pain out of writing assertions.

I am speaking from the API based backend world so YMMV. Once you’ve worked this way it’s hard to go back. Any developer can come in and confidently make changes. You spend way less time investigating regressions and broken environments, so you can release more frequently (which takes a whole other layer of pressure off the team)