Listen to this post
When a test fails for a reason other than intended, then upon investigating the cause of that failure the natural assumption will be that it is failing for the reason intended. Thus, the failure will mislead the team into investigating the wrong problem.
Anything that wastes developer time is to be avoided resolutely. Developer time is a highly crucial resource in modern development in that a) you need it to get anything done, and b) you can’t make more of it than you have. There are only so many hours in the day, and only so much time, focus, and energy a given person can devote to a task. Wasting this resource is like burning money in the street.
Furthermore, if a test fails for a reason other than you intend, then you obviously have created a test that has more than one failure mode which, if you understand
TDD well, would not have been your intention. Investigating how this happened is a real opportunity to improve your process once you identify the problem and focus on it.
Finally, if the errant thing that is making your test fail also has its own test (which, in TDD it absolutely should), then you’re also violating the third aspect of “good” tests. I will write about that next.