I have been reading Test-Driven Development in Microsoft .NET and I'm a bit disappointed. I am really trying to see the benefit of TDD, but I have to admit that it is escaping me. I see the benefit of using a tool such as NUnit or CSUnit, and plan on implementing the tool in our process. The part I'm having a hard time with is writing the test first then the code. It seems to me that by doing that you design your app to meet the tests and not to solve the business need. I know the idea is to write the test based on a requirement, but I feel that you will still compromise the design by doing this. The examples in the book have not convinced me that this is better at all. In some ways they are having the opposite effect. In chapter 5, Using TDD with ADO.NET it is recommended that typed datasets be used. They lost a fair amount of credibility with me at this point. Also it seems that more test code is written the application code. Is this normal?
We have an engine that calculates life insurance premiums. The database behind it is filled with dozens of tables with tens of thousands of rows. The object hierarchy that is created by this process can be somewhat complex, collections of collections of collections kind of stuff. The public API for the engine is relatively simple. Writing a test at the public API level would be simple enough, except that there are hundreds of thousand of combinations of inputs that can be entered. Would you try and solve this in a test? How would the internal and private classes, methods and properties be tested without breaking encapsulation? I can't have test code in a production assembly and I really don't want to manage a bunch of #if statements. Does that mean I have to make everything public? What about the classes and methods that have other object dependencies? How should this be handled?
My current plan is to implement some basic tests after the design and implementation. Have this as part of the build process. I am open to suggestions.....