Hi Neil,

That for you feedback. The article was, in fact, the findings of different attempts to make teams grow. So, I am happy to read your comment.

If you look at my other articles, you'll find that I write a lot about TDD. The reason is that I have discovered that most of the people does not follow the TDD practice correctly, and consequently, they do not obtain the benefits from it. I have some articles trying to address it (like this, or this) and I also recommend seeing the talks of Ian Cooper about it. But, in five cents, the problem is that most of the courses and material about TDD focus on QA Unit Tests instead of Agile Unit Test. QA Unit Tests focus in testing code, and it uses plenty of mocks. But if you refactor the code, the tests broke, so you have to care about two things. In TDD, the test should focus on functionalities, not in code. I have this old article that helped to steer my team. It is possible that even in the first stages, thinking in terms of BDD and behaviors will also help. Although the test code do not need to be natural language, but it should be human-readable.

About the objections of your teammates, I have seen them. And I understand their sources. About the objections, I understand them, and they have two sources. One is very understandable and has a solid foundation, the other arises due to bad TDD practices. The second one is that if you write QA Unit Tests, the test code becomes coupled to the production test, and you have to maintain twice the code, so your cognitive load doubles. But the first is that they have to learn testing properly inside the TDD mindset. That objection is understandable and reasonable.

What we do to solve the bridge of the lack of TDD mindset is: 1) a lot of pair programming, and even mob programming. And 2) katas. Although this last one is less popular, but I have colleagues in other companies that they do TDD katas every Friday.

I hoped it might help Neil, and thanks again!