Is it feasible to introduce Test Driven Development (TDD) in a mature project? [closed]

Question

• Say we have realized a value of TDD too late. Project is already matured, good deal of customers started using it.
• Say automated testing used are mostly functional/system testing and there is a good deal of automated GUI testing.
• Say we have new feature requests, and new bug reports (!). So good deal of development still goes on.
• Note there would already be plenty of business object with no or little unit testing.
• Too much collaboration/relationships between them, which again is tested only through higher level functional/system testing. No integration testing per se.
• Big databases in place with plenty of tables, views, etc. Just to instantiate a single business object there already goes good deal of database round trips.

How can we introduce TDD at this stage?

Mocking seems to be the way to go. But the amount of mocking we need to do here seems like too much. Sounds like elaborate infrastructure needs to be developed for the mocking system working for existing stuff (BO, databases, etc.).

Does that mean TDD is a suitable methodology only when starting from scratch? I am interested to hear about the feasible strategies to introduce TDD in an already mature product.

Answer 1

I think its completely feasible to introduce TDD into an existing application, in fact I have recently done it myself.

It is easiest to code new functionality in a TDD way and restructuring the existing code to accommodate this. This way you start of with a small section of your code tested but the effects start to spread through the whole code base.

If you've got a bug, then write a unit test to reproduce it, refactoring the code as necessary (unless the effort is really not worth it).

Personally, I don't think there's any need to go crazy and try and retrofit tests into the existing system as that can be very tedious without a great amount of benefit.

In summary, start small and your project will become more and more test infected.

Answer 2

Creating a complex mocking infrastructure will probably just hide the problems in your code. I would recommend that you start with integration tests, with a test database, around the areas of the code base that you plan to change. Once you have enough tests to ensure that you won't break anything if you make a change, you can start to refactor the code to make it more testable.

Se also Michael Feathers excellent book Working effectively with legacy code, its a must read for anyone thinking of introducing TDD into a legacy code base.