Let's say you are a developer (specifically, the team lead) and you want to improve the quality of your company's products. Since you cannot change the whole company, you focus on what you and your fellow developers can do to enhance the quality of the applications you create/maintain. You decide that this can best be done by embracing TDD for class verification and FDD for integration testing.
Since we are talking about .NET development here, let's be specific and use:
- MSTEST as a unit testing framework for the TDD
As a development house you already use TFS 2010 so the MSTEST solution is a given with its integration of code coverage and test pass validation at check-in.
- SpecFlow for the FDD
SpecFlow is more subjective, but I propose it as a FDD tool as it integrates well with VS 2010 and source control, and the gherkin/cucumber syntax is, I think, easier than that of Fitnesse.
Moving from "coding with ad hoc testing, followed by a release to QA" to a "TDD/FDD" approach will save time and money over the life of an application—but, it will extend the time a program spends in development over the ad hoc approach (although arguably the QA time should reduce as QA should then mostly find system test faults rather than those and integration and class bugs devs now find and fix sooner).
Assume some minor TDD/FDD projects have already been completed so your company is not overly nervous about the technology, but have yet to "go for it" with a full size project.
But in this business, development is a different cost centre from QA, and both are different from support and operations.
So, how do you sell the benefit to the company of adopting TDD/FDD to development managers who are held to account for the increased cost (i.e., time) of the development department?
This, to me, is all the harder given the benefits of failing early, etc. seem largely unquantifiable.
How do you go about winning hearts and minds on the topic?