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?
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
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.
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.
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.
I would suggest you to implement those unit tests. TDD is a way of making sure that your code/feature-implementations work as expected, even if it means legacy code. On the brighter side, adding unit tests might help you to find unexpected bugs, besides giving you the opportunity to refactor your code. Keeping in mind the practical side of the argument, the implementation cost. This might come as a obstacle given that there will other work. Therefore, it would be better to take a gradual approach of introducing these unit tests. May be you can organize the features as per importance. The following links from quality assurance services might be of some help to you,
https://blog.qasource.com/8-ways-to-succeed-with-agile-qa/
https://blog.qasource.com/resources/software-testing-process-in-agile-development-what-works-best
