write tests for old or new features?

You have a pile of legacy code that’s hard to modify, hard to test, and never seems to be bug-free. You have some testers who are available to be moved to the front of the flow to write regression tests. Is it more cost-effective to have them write regression tests for current features or for new features? Does the answer depend on aspects of the environment, or the tools available?

I must admit I’ve always tended to favour testing the new stuff; what would you do?

3 thoughts on “write tests for old or new features?

  1. Good Question! I don’t have a lot of experience with larger teams and separate testers, but when I’ve been in the situation of working on a legacy codebase, I’ve tried to write tests for the areas of the system that I’m about to touch.

  2. I agree with you that it would be best to ensure that the new features are well tested. I think this would be a good idea so that you get the reputation for writing robust features. Once you’ve shown you can do that you may have more political leverage to get enough time and resources to test the old stuff too.

  3. My policy is usually: test new stuff, and test the old stuff the new stuff touches. Basically anything that interacts with the new stuff and could potentially break. I don’t see any reason to go out and test old stuff that is not under a pressure to evolve, as presumably it already works. For the same reason, I would never refactor code that did not need features adding. Both are wasteful IMO.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s