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?
1
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.
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.
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.