I agree, but I typically count "small, deterministic, fast" tests as unit tests. Ideally, you'd test everything via the public interface (be it an API, a UI, o

I agree, but I typically count "small, deterministic, fast" tests as unit tests. Ideally, you'd test everything via the public interface (be it an API, a UI, or an SDK.) That would make it so you only change your tests when the user-facing behavior changes. But your public interfaces are typically doing slow, non-deterministic things (e.g., calling external services.) Therefore, they aren't easy to test. Some people fix this by testing individual classes. It's better (but harder) to isolate slow/non-deterministic dependencies to small services that can be faked/stubbed out. Then you can have your cake and eat it too: Your tests are fast/deterministic, and they can still be end-to-end (and therefore not need to be updated whenever internals change.) Your intuition is leading you in the right direction. There are ways to write "end to end" tests that have all the benefits of "unit" tests. The (free) book "Software Engineering at Google" has chapters on testing that describe the techniques better than I can. (They reach the same conclusion about how testing internals ends up being less useful than testing the public interface, and then they explain techniques/tradeoffs.)