I tend to take a similar view. I will write "unit tests" but they will be at the level of a whole module or assembly, and so often blur the lines with integrat

I tend to take a similar view. I will write "unit tests" but they will be at the level of a whole module or assembly, and so often blur the lines with integration tests (particularly because spinning up a test data store is often easier than buggering around with mocks). "Real" integration tests look at multiple modules or systems. You catch a lot of bugs this way, have far fewer tests to maintain, and have the freedom to make internal changes without worrying that you're then going to have to fix up 100 tests to get your build working again. And you still get the coverage you need. It's a better world. Tbh, I find writing a tests at the class or method level only to be absolutely ridiculous except for cases where I'm dealing with a method that does something particularly tricky or esoteric. Again, for all this context is key. As developers we should be thinking about what we're doing and the trade-offs inherent in that, not just blindly following a set of rules that say "You should do X; you should unit test; you should write tests for every method of every class."