How did you adapt your unit tests to deal with changing requirements?

Question

I have a project where I've been using TDD and unit tests as "software vises". In essence I translate the requirements into tests that verify that the code conforms to the requirements. I rarely have to go back and edit the unit tests, which rather is the point: only the "real" code should be modified. At the moment, there are 900 unit tests.

Now some requirements have been changed by the gold-owners. Since the former requirements are so thorougly encoded in the existing unit tests, it seems that changing them to conform to the new requirements would be inviting disaster. How do you adapt your unit test suites to handle this kind of change?

Answer 1

Per definition the unit-tests don't replicate the requirements for the application. They describe the requirements for a module. That's a difference, the module can be reused even in an application with different requirements or isn't used at all. So the changing requirements don't affect real unit-tests (except that you have to write new for new modules or abandon old tests for modules no longer needed for the changed requirements).

On the other hand: acceptance-tests deal with the requirements on application-level. So I think you talk about acceptance-tests.

I would add the new requirements as new acceptance-test. But for the old ones you have to look through them, how they are invalidated by the changed requirements.

Answer 2

I would add the new tests and make them pass. Then you look at what tests have been broken as a result. If you believe the old tests are in contradiction to the new tests then you may have to remove the old tests. Otherwise, you alter the code to make the old tests pass as well.