Visual Studio Team Suite: great for TDD (flame me :)
I was at the INDA meeting last night where Robert Scoble gave a talk on the rise of blogging and a panel answered questions from the floor about the future of .NET programming from Vista and beyond.
Pretty quickly the discussion got round to Visual Studio 2005, with all its little imperfections. One thing that really got people going was the recent MSDN article which attempted to describe how to use Team System to write code in a test-driven way. The article was widely ridiculed and for good reason: there was nothing remotely test-driven about the approach it described. It used tests, sure, but being test driven is about a lot more than just having tests. I didn’t like the article more than anyone else, and added my own 1/9 vote. I’m glad they took it offline, because I wouldn’t want people to be misled about the aims of test-driven development.
That said, the tool itself has actually got a lot of features that make it an efficient IDE for writing test-driven code. When it comes down to it, the core tool you need for unit testing just calls a bunch of methods and displays their results — it doesn’t get much simpler (Kent Beck even says you should write your own). On this measure, Team System performs perfectly well (how could it not?), as does NUnit.
Team System though has a couple of extra features that improve on the regular NUnit experience. For one thing, you get first rate IDE integration. Once you set the test as the startup project, Ctrl-F5 runs the tests, F5 on its own runs them in the debugger. You can do much the same with testdriven.net, or configure NUnit to start up in a similar way, but having everything a keystroke away is essential once you get hooked on the red/green/refactor rhythm.
The other killer feature is code coverage. Just by selecting an option in the build properties you get full analysis of what lines of code your tests hit, with red/green highlighting of each line and percentages for each namespace, class and method. Again, NCover does the same thing (particularly when you combine it with NCover Browser), but IDE integration brings it that little bit further.
Add all this to the base Team System functionality, with its check-in policies, work item management and proper source control (not to mention the rest), and you’ve got a great tool for using (and enforcing) TDD in teams.
Yeah, they’ve included a lot of stuff that isn’t of interest to TDD fans. If you’re test driven, you won’t be interested in creating “tests” from code you’ve already written, but then you won’t be interested in the support for manual test scripts either. Just ignore it: someone else wants those features even if you don’t. Most of all though, don’t reject the tool just because someone wrote a crappy article about it. Give it a chance, and you might be pleasantly surprised.