I'm glad you expanded on your previous answer. This is a take I've come to highly agree with. This even can apply to basic CRUD app work. For example, in a simp

I'm glad you expanded on your previous answer. This is a take I've come to highly agree with. This even can apply to basic CRUD app work. For example, in a simple layered architecture that works like this: [Controller] -> [Service] -> [Repository] -> Actual DB I've found integration tests highly valuable at the Repository level. They've helped me not only catch bugs, but also guided me though migrating to a completely different DB. So, I am really happy with that choice. Unit test + mocks would have been of nearly zero value here. I've found DB-isolated tests beneficial at the Controller and Service layers. But keeping the tests for these two layers separate was kinda silly. Ultimately I want to know that the controller + service yields the result the consumer wants. For the sake of validating the logic in these classes, why would it matter if it took path A or B? If I had put these tests together, the ration of tests to lines covered would've been way less, with a relatively minor impact on readability.