I think I agree with this, although I also think a lot of people would still call this integration testing. Basically a lot of code units are implementation det

I think I agree with this, although I also think a lot of people would still call this integration testing. Basically a lot of code units are implementation details and you want to be free to refactor them fearlessly without having to write double the code each time tightly unit testing each part. Much better to narrow your system to a few well defined boundaries that deliver some clear value. The code behind that interface can be as deep as you like but you don’t really need to push tests down into the depths. As I say, some people will still think of this as integration testing just because there’s a lot of moving parts working together. But often you’re just testing fairly pure code with no external or IO dependencies so I’m happy thinking of these as unit tests still. Where those types of dependencies exist I do still mock though.