Test Driven Development when the specifications change

Question

These days, it's fairly common for me to be tasked to make a change that actually breaks the prior spec. I know that one of the major ideas behind TDD is to have a suite that verifies all your changes didn't actually break anything, but what do you do when the change you need to do, by it's very nature, actually must break the unit test?

---

How to do Test Driven Development is a similar, related question but it is subtlety different from my question. In my case, I already have the test and the specification has changed. In that question, the OP does not have the test yet.

Answer 1

The advertised cycle of TDD is write tests until they fail then hack at the code until they pass again and then refactor while keeping all test succeeding.

When the spec changes you will need to remove the old tests that would verify a violation of the new spec and write new tests that will verify the new spec.

Answer 2

TDD "by the book" has a specific cycle, and specficially for changing specs, this cycle should ideally look like this:

1. write one test according to the new spec (-> "red")

2. change the SUT ("subject under test") to match the new test; depending on the change, this might break some old tests (-> the new test goes "green", but the old tests become "red")

3. Change the old tests if they can be modified to test the SUT according to the new spec. Or, if that is not possible, delete them (-> "green")

4. repeat from step 1 until you have enough tests for validating the whole spec, and the SUT implements it

Of course, in a real world scenario you will try to avoid situations where adding one test in step 1 will lead to the deletion of 100 existing tests in step 3. If that is the case, the tests show up that your original design was not evolvable enough, or your tests were not DRY enough, or the spec change was so big that you actually had to drop most of the original SUT and write a new one.