Listen to this post
When organizations adopt TDD as their development paradigm, early results can be quite good once the teams get over the initial learning curve. Code quality goes up, defect rate goes down, and the team gains confidence which allows them to be aggressive in pursuing business value.
But there is a negative trend that can emerge as the test suite grows in size over time.
Generally speaking, TDD is an Agile process and so new requirements flow into the team on a regular pulse, through push or pull. A new requirement in TDD always means a new, failing test. Then, work is done to make this new test pass. However, sometimes this causes older tests to fail. These tests must be maintained, and this work feels wasteful as it adds no new value. Over time, more and more older tests must be maintained as new requirements are prioritized and, eventually, the process seemingly becomes unsustainable.
This is avoidable and is in fact a subject that high-quality TDD training should focus on.
When two tests fail for a single reason this indicates that this problem has begun and must be addressed before it gets worse. Understanding that his is not acceptable is the first step to correcting it.