TFD TDD relevance in larger products

Question

I was wondering about the feasibility and the realistic gains we achieve by following the Test First Design approach in larger products.

Although I am a strong believer in deciding the scope before jumping into coding, for a larger product, I"m really not sure if the TDD holds.

Realistic Problems with a larger product:
1. The size of the product makes it much harder to maintain all the test cases.
2. The unit boundaries, slowly become less defined and sometimes unwanted coupling results between different units.
3. Testing a unit might not suffice the functionality of the developed structure as such (A possible result of tight coupling)
4. The initial thought process and the vision might get diluted with the product size. This in turn dilutes the definition of the units and test cases become mere process requirements rather than serving the purpose of being the guardians of a piece of code.

My view no this situation of product growth is to stop the growth of the product and remove the unwanted bits. Start to clean up the product to have only those features which define the product. The other features, either already developed or being developed can be given as addons. And these core set of features of the product need to be guarded using a strong set of Unit Test Cases which define the Unit's functionality alone.

Any more suggestions? I would love to hear from you guys as I currently am facing this situation of coupling of units and the redundant test cases which actually don't do much. And all of this is introduced due to the size of the product growing almost each and every day.

Answer 1

1. TDD will work for any size project. Personally I work on a system with at my last count, around 650,000 lines of C Sharp. We could have never approached such a size without a suite of tests backing our changes up and preventing regressions.
2. Remember the difference between Test First and Test Driven (TDD). If you follow test driven development and let the tests drive the code you create, coupling should not be a problem. The same cannot be said for TFD, it would be up the developers to control this level of quality.
3. See point one. In fact, unit tests would be the best bet for advance functionality anywhere. Check this article about how many tests you need per path in your code. You could use integration tests but as the article points out, the number you would need would be more than the number of unit tests you need.
4. This is up to the team. Test code should be treated as a first class citizen. This is especially true if the project is going to be as "large" as you reckon, the slightest regression could be costly.

With regards your last question, my recommendation would be to ensure you core domain logic is as tested and stable as possible. It will be up to you and your team to find out what is the "core" of your application. The remaining infrastructure can be fairly loose, but there should be little to no logic in this layer anyway. Lock down the domain, and the rest should follow suit.