Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. 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

In an transitioning agile environment, if there was no Test Driven Development (no unit tests created), should you create unit tests to catch up on technical debt? And to what extent? Should they cover every little feature, or more of a happy path style?

share|improve this question
If you do TDD, you will have unit tests, but that doesn't mean that all unit tests are created as a result of TDD. I can't see a situation where unit tests are a bad thing. – corsiKa Jul 12 '11 at 16:10
up vote 18 down vote accepted

I would suggest that you go back and do those unit tests when you are required to refactor that area of legacy code. The approach for do this is described in this question.

When you are working with legacy code with no unit tests, its the same principle and techniques to add them regardless if you are doing TDD or not.

I highly recommend Working Effectively with Legacy Code

share|improve this answer
+1 on the book referral, it cones highly recommened by a few devs I know. I would add in doing a fast search in your code for anything else that might utilize the object/class/method etc that you are modifying, and add unit tests that reflect the behavior expected by those things FIRST (and make sure they pass) before you then write unit tests for the new functionality or bug you are fixing.. that makes a slightly better guard against breaking existing functionality with your changes. – Chuck van der Linden Jun 23 '11 at 5:27

No. It's too late for the tests to affect the design, so you can't get the major benefit of TDD.

What you can do, however, is to write tests as you work on the code. Say you've got a method that's too long. Write a test of a little piece of it, assuming that little piece had been extracted into a new method. Now extract that method. Or say a bug report comes in; this is an opportunity to improve your design (and incidentally your test coverage). Write a regression test that demonstrates the bug. Study your code to understand the root cause of the bug. Now write a good unit test that expresses how that root cause should be behaving. Make that test pass, and if you did it right, the regression test will be passing, too.

TDD tests really need to happen (a) in advance of; and (b) very close in time to the code that they are testing. So accept that it's too late to retrofit your code "for the sake of TDD"; just get into the habit. With the practices outlined above, the code that needs the tests will get them.

share|improve this answer

Covering the existing code with unit tests might be worthwhile if you target the area of the code that have higher probability of being changed in upcoming releases.

That way you will build a safety net around the code that likely will be changed (new features, refactoring, bug fixes etc).

Targeting the code that has higher logical complexity and covering it with unit tests will provide potentially higher ROI as possible mistakes introduced in that code are more likely to be discovered (faster/easier) with unit tests than during system or integration testing.

share|improve this answer

The key question is can you afford for it to go wrong?

And the answer to this quite often is dependent on how quickly you can fix the problem if it occurs - debug it until it works in production. While not a nice place to be, for some things that once done, should never need to be revisited you can get away with having no tests.

If your business / lives depend on it working or if it goes wrong it would be hard to fix (pentium bug) then definatly anything you touch should have a safety net of a test put in it's place.

If it doesn't really matter if it goes wrong, don't worry about it. Concentrate on the parts that really do matter.

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.