I was reading some questions about TDD here and came up with my own.
I understand TDD to be a way of developing or capturing the detailed, internal specification/requirements for code in the course of writing that code.
We proceed step by step and add falsifiable propositions to the specification body in the form of tests. We show these to be false and then write code to make them true. Then refactor while keeping them true.
The problem is, how do we know that all the existing tests are staying falsifiable (with regard to their original feature)?
In the course of adding some new element to the code via this process, suppose that some tests can easily become outdated in the following sense: those tests were initially associated with some specific change, and if that change is now reverted in the current baseline, perhaps they still pass. Whatever is making them pass now is not that original feature which flipped them from fail to pass.
Those tests/specifications seem like garbage which adds bulk to the specification base without any substance. Or is there still value in a test which doesn't go false if the original code change which made it true is reverted, and it's not obvious what other code change to the current base would make it go false?
Is there some TDD process to identify these tests? And are they then removed or rewritten or what?
Or, alternatively, is this entirely prevented somehow?