> TDD and exhaustive unit testing make the maintenance process harder because you don't know if a test is useful or not. TDD was later given the name BDD (Beha

> TDD and exhaustive unit testing make the maintenance process harder because you don't know if a test is useful or not. TDD was later given the name BDD (Behaviour Driven Development) to emphasize that you are not testing, but actually documenting behaviour. What kind of behaviour are you documenting that isn't useful and why did you find it necessary to document in the first place? > If you follow TDD, most unit tests are re-written all the time. What for? If changing requirements see that your behaviour has changed to the extent that that your unit does something completely different, it's something brand new and should be treated as such. Barring exceptional circumstances, public interfaces should be considered stable for their entire lifetime and, at most, deprecated if they no longer serve a purpose. The implementation beneath the interface may change over time, but TDD is explicit that you should not test implementation – it is not about testing – only that you should document the expected behaviour of any implementation that may carry out your desired behaviour.