In my experience discussing this topic is difficult without defining “unit” in unit testing. Similarly, “integration” testing is also something that means diffe

In my experience discussing this topic is difficult without defining “unit” in unit testing. Similarly, “integration” testing is also something that means different things to different people. So let’s instead talk about other dimensions: Are you verifying that your application conforms to its requirements? This is something that is usually done on a System Under Test the size of at least an application module, a service or set of services. In some cases, for legacy systems, I have even targeted the UI with these tests. Normally for this type of testing the SUT cuts out third-party dependencies to make things controllable - instead you point it at semantically equivalent but shallow fakes for these dependencies. These are nice tests that are quite stable over time and resilient to changes in implementation details, allowing you low-cost refactoring. These tests are good drivers for technical tests - the tests that support the development process itself. These typically target smaller Systems Under Test. For example, checking a calculation function, checking that you can save and load all documents using a generator and property-bars testing etc. If you let the high-level requirements tests lead my experience is that fewer of these low level technical tests are necessary than a bottom up TDD approach would lead you to. The low-level “unit” testing with micro units (classes, methods, functions) is the “wax on, wax off” of test driven development. It exists to establish a habit and then as your experience grows you can combine methods and eventually select the solution that fits best on the exact context. I think Alistair Cockburn called this shu-ha-ri levels of development.