Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a personal project that doesn't have robust testing. I had a bit of TDD going on at the beginning, but it quickly became counterproductive as the project details changed dramatically over time. So a lot of previously written tests have become useless.

Now that the project solidified a bit, I dont' think big changes are likely. Should I go back and rewrite those tests for old functionalities or just start fresh and write tests for new functionalities only?

share|improve this question
do you have time / how painful would it be for you to rewrite those tests for old functionalities? without that knowledge, it would be difficult to answer the question – gnat Jul 17 '12 at 6:46
up vote 5 down vote accepted

Whenever you want to modify an untested area, rewrite the tests for the small area your are modifying and then do your modifications.

This will allow you to rediscover/specify old code.

share|improve this answer

As long as the old tests were good and the business rules they cover are still valid then they are worth revisiting. Hopefully it just takes a few alterations to those tests. The most important thing is all the business rules are covered in tests, whether the business rules are considered "old" or "new".

Unfortunately, going back and doing this in bulk is going to take a bit of time. But in the end it will be worth it. Because in the end, the number of bugs found should be much much less. Hopefully you don't fall into this same pit again. A lot of people who do TDD tend to skip fixing tests when they are in a crunch or there are major changes. But I think that is more counter-productive, because you aren't sure what the effects of changing a particular module will have, and you could end up with even more bugs. Tests should be treated as another consumer of your code, and should be treated in the same category as say the user interface.

share|improve this answer

I personally think you should treat this situation as if the old code was "legacy" (as in Feathers' book "Working with Legacy Code") and go on from that point.

That mean, redesign all "solidified" but untested parts, one at a time, tests-first. Maybe some parts get new. simpler, implementation, maybe not at all since the existing one is fine.

But it is just a feeling, I wasn't in a similar situation yet.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.