Exactly!
Well... not only. I got carried away by the enthusiasm.
The problem of TDD is that it has so many good things that it is difficult to say, that is the good one!
I have dedicated just one article for looking to all of them:
But, if I had to choose a main benefit, I would choose communication. Once you deeply understand TDD, you can leverage on it to improve communication between roles. In fact, tests are nothing else than examples, so you can discuss the exact examples with the PO, and make them drive your implementation.
For me, it is so important, that I even dedicated one article to that:
And yes, I placed the value in a pyramid, intending to leave behind the testing pyramid, that is the QA testing pyramid, and it does not help developers. In fact, in TDD "unit test" does not mean an isolated unit of code, it means an isolated behavior. That is not me, that is Kent Beck and the Agile Alliance:
«The outcome of a unit test is binary: either “pass” if the program’s behavior is consistent with the recorded expectations, or “fail” otherwise.»
