At my last company, we built a graph of when outages occurred versus test coverage by service

Do you think early startup product might be an exception? Since whole features can be quickly ditched frequentl. Sometimes even complete product pivot.

While I agree testing in general is a must, I'm still not sold on unit testing as a general tool. For stuff like core libraries or say compilers, sure, unit tests are great. But for the levels above I'm leaning towards integration tests first, and then possibly add unit tests if needed. After all, you can't not have integration tests. No matter how perfect your Lego bricks are, you can still assemble them together the wrong way around.

- Think about clear interfaces - Handle edge cases explicitly - Create clean separation of concerns - Build proper startup/shutdown sequences If you do all of these things to start with though, then what's the value proposition?

I think testing as a cost and manual QA has another cost. Depending on the cost over time (maintenance or manual QA) and the upfront cost, as well as the risk of refactors, which needs tests, there are moments where one option is better than the other. It changes, so it is worth considering.

IME end-to-end tests in a browser really help with services that have a lot of parts to integrate, but damn they are hard to make reliable. One challenge is animation and timing races, supposedly Playwright can address many of those. Another is some infrastructure like GitHub Actions can be randomly resource starved, such as causing the Chrome Driver to become unresponsive. Automated retrying is one workaround, at the cost of possibly papering over rare race and timing issues. Of course unit tests are nice and fast and narrow. But refactors could render a large portion obsolete, and they won't prove things work together as a whole.

>The most insightful point is how testing fundamentally changes your design for the better. When you have to make something testable. When people say this type of thing I consider it to be kind of a code smell that they're testing at too low a level and tightly coupling their tests to their implementation. It is true that the pain of tightly coupling your code to your tests to your implementation can drive you to unwind some of that tight coupling but that still leaves your tests and your code tightly coupled. I find the best bang for my buck are tests that are run at a high enough level to make it possible to refactor a lot and safely with a minimum of test changes. Technical debt that is covered by tests doesnt compound at nearly the same rate.

Author of the original post here. Thanks for such thoughtful comments and reactions. I'm glad I "stuck a nerve" for at least one person!