Visual Studio Team System has many great features baked right in. Here's what might be a typical experience:
- Fire up the Application Connector Designer. Plot systems... Generate projects - CHECK!
- Bring up a Class Diagram. Model classes and interfaces... Generate files - CHECK!
- Add some code here and there... CHECK!
- Create my Test Project... CHECK!
- Right-click on some code, choose "Create Tests"... Add unit tests - CHECK!
- Start working on my tests...
Hmmm... Wait a minute. Something is not quite right here.
One of the ideals of Test-Driven Development (TDD) is that you should not write any implementation code without first having a failing test. Also, a tactic of TDD is to address one test at a time from a list of continuously-evolving candidate tests. These ideals are described in the excellent books "Test-Driven Development in Microsoft .NET" by Jim Newkirk and "Test Driven Development: By Example" by Kent Beck.
With these time-saving VSTS tools at my fingertips, I'm enticed to take the automatic route and generate as much as possible - projects, classes, unit tests, etc. However, when I use the Class Diagram tool and then generate my tests from the resulting classes, I'm creating code without first having a failing test. If I opt to follow TDD by manually creating a (failing) unit test first and then emploing the Class Diagram tool, I have to sacrifice the productivity other developers enjoy with the "Create Tests" option. (Almost by definition whenever I run "Create Tests", I've probably written code without a failing test.)
I suppose one argument could be that by using the Class Designer et al., you are not actually writing "implementation", just the scaffolding upon which you will add the real mechanics. You create your unit tests from the shell classes with empty members, then start addressing all of the Assert.Inconclusive() results.
That argument only goes so far - the concern remains that the "Create Tests" feature generally runs contrary to the approach where you maintain a list of candidate tests based on functionality. Instead, you see the "Unit Test Generation" dialog, choose your classes and members, and effortlessly now have a suite of tests. Unfortunately, these are based upon class members and not on specific slices of functionality to be tested.
This boils down to a basic concern that the "easy" or even "normal" way of developing systems with VSTS can run counter to some of the tenets of TDD.
Let's be clear, nobody is forced to use these tools. However, my job as architect and standards-driver could become harder if I need to tell developers not to leverage available automation for sake of TDD purity, especially given looming deadlines.
Are there any features still to be added to VSTS which could help with this? Maybe a feature to help people track candidate test lists? (A new view into the Task List?) It might include a wizard/designer such that I can take a test from the list, select a template, or target method(s) and have a shell test generated (and the test crossed off the list.) Perhaps I could right-click on a method, a block of code or even the state of an object in the debugger and say "Add to Candidate Tests" so I could review it later?
Are my concerns unwarranted? Does anyone have experiences implementing the “create a test first, then implement” approach in a large-scale .NET project? If so, how do you feel VSTS will affect your approach?
-Chris