The best testing strategy is situational, contextual. Categorical statements are rarely universal. Is the abstraction stack deep? Integration tests cover a lot

The best testing strategy is situational, contextual. Categorical statements are rarely universal. Is the abstraction stack deep? Integration tests cover a lot more, while unit tests won't give you good confidence that the composition works. Unit tests are useful close to the control flow leaves, and where data flow is bottle-necked. Unit tests are often busywork in the middle of the stack where code up, down, left and right needs to be mocked or stubbed, and your test is just a restatement of the implementation logic written inside out. Hopefully there's enough of a modular architecture that whole submodules can be replaced with a simple API for higher level testing. Is the abstraction stack shallow and the data model simple? The difference between an integration test and a unit test is small, and if you replace the expensive bits (database, RPC generally) with mocks, fakes, stubs, then they're almost the same. Is the data model complex? Unit test setup is going to be expensive for every combination, while integration tests can leverage the code itself to generate the data model. Unit testing will likely only check one dimension of data complexity, but complex data models have multiple dimensions and for good coverage, you need cross-product tests which are expensive to run even as unit tests because of combinatorial explosion. I don't think there's a cheap simple answer. You need a mix across the spectrum and try and not run tests when you don't need to (smarter CI). Is the design changing a lot? Unit tests will be very brittle and you'll spend a lot of time rewriting them, as abstraction layers merge and split both horizontally and vertically. Integration tests are much more valuable. Having a lot of unit tests can inhibit refactoring, and refactoring debt will ironically create more tests to guard against regression from the bugs that come from complexity. Do you need to know that customers are going to be able to perform their basic routines right after a release? Unit tests won't give you this confidence; you need the highest level integration test driven from the UI, a smoke test. I don't think telling people to concentrate on one thing vs another is useful without context.