Hi Devin,

I know both schools, I have tried both, I see value in both, but this article is aiming to those people that have tried TDD and have failed.

For example, the London school is great for cases of complicate algorithms, in which the algorithm is clear, the result is also clear, and you need help to go step by step and, at the same time, ensure that there is a good implementation.

But that is not the general case. The general case is that programs change continuously, we have to adapt the design and architecture continuously, and we need to keep track of actual requirements better than the code implementation specificities. That is what this story is aiming to help. Because that is the case of most of the companies, and the case that I have seen more people fail with TDD, until the point that they have said that TDD is useless.

We both know the difference between the two schools, the intentions behind each one, and the techniques behind, but most of the programmers don't. They do QA unit tests, not because they try to follow the London School of TDD, but because it is what they learned, and why not, what it is easier to code and have the code coverage to pass the pipeline checks.

So, I am not writing against London School of TDD. I am writing against adding mocks for no reason. As you have seen, I value both approaches, I think that each one has its purpose, but now my objective is trying to help the people to learn and understand the origin of TDD and how it got value.

Thanks for the feedback!