I was a huge fan of this article and Misko's accompanying talks back in 2012 or so, but a lot of this hasn't aged that well. These ideas all assume that in all

I was a huge fan of this article and Misko's accompanying talks back in 2012 or so, but a lot of this hasn't aged that well. These ideas all assume that in all cases, the class should be the unit under test, and you can see how this plays out in Angular, where the command-line tool will generate stub unit tests for every new component you create. If you fill out those tests with the aim of maximizing code coverage, then what you'll find is that all of those tests will need to be rewritten at the first refactor. On a personal project, that might be an enjoyable way to spend a bit of time, getting to understand your project better, but on a team with actual deadlines, there's not going to be enough time to do that. Either you remove the tests entirely, or you put off the refactor indefinitely. Class-based unit tests lock you into a specific implementation, providing a checksum on the current behavior, making it as hard as possible to fix an actual bug when it's discovered. Collaborators-included unit tests on the other hand, do not break unless your product is broken. It can be harder to chase code coverage when you're doing laparoscopic surgery on your code, but the end result is that every conditional has an actual use case behind it, and if the requirements change, you can see the name of the test with the bad requirement and delete it. I still think that a lot of the patterns that make your code testable are still good though. It's not always clear at what level of abstraction you want to start mocking. Do you mock HTTP? Do you mock a martialed API? Do you mock a business logic abstraction that depends on that API? If you use DI for all of these layers, then you don't have to get it right the first time. You have options when you're writing your tests, and can use concrete or mock collaborators according to whatever your current need is.