Good article.

I got my first taste of TDD many years ago in a London based software company that did indeed put huge emphasis on mocking. It doesn't work. TDD is massively overrated too, tests yes, all day every day, but it should not be tests that drive your design, it should be design that drives your tests.

Mocks are a necessary evil. You probably can't call an external web API as part of your test suite. You may have code that is too slow to call often in your test suite. In these cases you've got one option and that is a mock. There are probably other situations.

There are however, two huge problems with mocks. They cripple your ability to refactor because they couple your implementation to your test code. Tests with mocks are usually much harder to understand than tests without them.

The dirty truth is that integration / functional tests are brilliant tests because they find bugs. I want to run a test against a real database or filesystem. I want my test suite to be as close to my production environment as possible, because I know, from spending thousands of hours writing code in large teams with large test suites that those are the tests tell you if there is a problem.

Testing is hard, and there is no shame in saying that some code is just not worth the effort of testing. But test what you can, and test it as honestly as you can.