There seems to be two aspects to this discussion. One involves questions of process, enforcing TDD, and whether or not TDD can save a bad team from producing b

There seems to be two aspects to this discussion. One involves questions of process, enforcing TDD, and whether or not TDD can save a bad team from producing bad stuff. The other is the question of what TDD can offer for a skilled team with an intelligent approach to development. Mixing these aspects leads people to dismiss TDD because they've seen teams fail by doing TDD in a bad way. Another question: is there a way to structure software so that questions of boundaries and collaborators become less troublesome for testing? I think a promising road is in value-oriented programming without side effects. Another way to see that: if you need a lot of tedious mocking to test your unit, maybe the unit should be redesigned to have fewer collaborators, or maybe you should move the complex logic to a pure function, and so on. Maybe TDD difficulties are showing us that there is something wrong with how we write code. After all that's what it's supposed to do.