I'm a massive fan of unit testing, but I mostly agree with the observations. However, I (mostly) disagree with the conclusion. The problems with unit testing I'

I'm a massive fan of unit testing, but I mostly agree with the observations. However, I (mostly) disagree with the conclusion. The problems with unit testing I've seen to come from the following anti-patterns in various combinations. 1) The use of unit tests as the exclusive automated test type. ie; No functional tests, integration, etc. 2) Test doubles for most or every dependency, even purely functional dependencies like math libraries. 3) Not using the appropriate kind of test double for the test at hand. (Dummies vs Fakes, vs Spies, vs Stubs, vs Mocks) 4) The overuse of mocking libraries. Mocking libraries have their place, but in opinion, are used approximately a hundred, perhaps even a thousand times more often than they should be. I use them to create test doubles in exactly three scenarios: 1) A dependency that does not have an interface, usually a third party library. This usually happens in one place only, and is used for writing the wrapper code test. 2) A dependency that has an incredibly large interface and/or dependency graph where building a set of stubs or spies is simply not worth the effort. 3) I want to test weird edge cases that's not available any other way, such as theoretically unreachable code. These should not be the majority of your unit tests!