- 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.
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.