I’m building a new application and trying to adhere to “test-first” development as faithfully as I can. I’m finding myself in situations where I need to implement/change a feature that has an effect of invalidating a number of existing unit tests. How should I be dealing with this? As I see it, there are 3 options:
-
Update or remove all existing tests to meet the new feature requirements (adding any more as necessary), then implement the feature
-
Implement the feature first, run tests to see failures, and update or remove any failed tests (adding any more as necessary)
-
Add new tests for the new feature,
implement the feature, run all tests
to see the old ones fail, remove or
update the old tests as necessary
The first option adheres to TDD, but can be excruciatingly counter-productive. The second option is the easiest, but you wouldn’t be faithfully testing first and may not be properly “covered.” The third option is a compromise of both and attractive to a degree, but you run the risk of re-writing a test when you could have just updated an old one.
I don’t feel like I have any clear strategy here. What do you do in these situations?
I would choose one test and change it to require the new feature. If there aren’t any obvious candidates, i.e., it is truly new, I would create one. I would then write the code to pass that test. At that point I would run my other tests and notice that some of them fail. At that point, I would revisit each test in turn either correcting the test to reflect the new feature (so it would pass with no other code changes) or update the test with regard to the new feature (which may require some further changes to the code under test).