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?

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

+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 LindenJun 23 '11 at 5:27

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.

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.

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.