3

This question already has an answer here:

I am beginning development on a legacy codebase and adding new functionality. The legacy codebase has no tests defined at all, and I dont have full control over it. I want to use TDD to help ensure the code I write doesnt break anything, but I can't afford to spend the next 2 months designing tests for the legacy codebase.

Should I just focus on TDD for the new code, or is there a middle-ground approach?

marked as duplicate by Bruce McLeod Nov 25 '14 at 23:47

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • If a question is to help with home work, you need to mention it in the question. – Bruce McLeod Nov 25 '14 at 23:54
4

This book is exactly what you need: Working Effectively with Legacy Code by Michael Feathers.

Michael offers several approaches to TDDing legacy code. One of those is: Before you add a new feature, write tests in the area that you will change.

This approach gives a number of benefits:

  • Writing the tests will give you a certain amount of confidence that you're not breaking anything (at least, in the area of the tests).
  • Focusing only on the area that you will change helps to limit the amount of time you spend writing tests for legacy code.
  • Over time, you end up with more and more tests in exactly those areas of the code that change the most. That's a big win.
  • In order to get the nearby code under test, you likely have to make it more testable. This sounds like a disadvantage--more work! gaah!--but you end up with code that is more testable, and therefore more changeable. Another big win.

See the book for more ideas. I give it my highest recommendation.

Not the answer you're looking for? Browse other questions tagged or ask your own question.