A number of enhancements have been made to the intellisense and refactoring features build into Visual Studio 2010 which should greatly enhance support for real test driven development. This post documents my investigation into how well this works in reality.

First I need to recap what I mean by "real" test driven development. This is where each test is written before the code itself, which assists the developer in focussing on the requirements, and essentially defining these requirements through the test alone. Once the test is written, classes and method stubs are added in order to allow the project to compile, the test is executed (and fails), then the classes & methods are updated with the required functionality, and the test re-run to ensure that it passes. See Test Driven Development on wikipedia and the book Test Driven Development by Kent Beck for further reading.

So to use an example that has never been done before (not) lets implement a calculator class, and create a class library (CalcLib) and related test assembly (CalcLib.Test) in a new solution. Add a reference from CalcLib.Test back to CalcLib.

Lets start by adding a test for the constructor - we (arbitrarily) decide that the constructor should initialise the running total to whatever we ask for, so add a new test class CalculatorTests.cs to the test project, and add the first test ConstructorInitialisesTotal to this class.

Now if we start typing the test, by created a new instance of the Calculator class, something annoying happens with intellisense - the test class itself is the default choice, so even if we type Calculator in full and type the first parenthesis, it autocompletes as CalculatorTest instead, and we have to Ctrl-Z to get what we wanted. Grrrr.

Notice that intellisense now has an initial item which says <Ctrl-Alt-Space> - type that - I dare you! This switches intellisense into Consume First Completion Mode, which is what we have been missing all along. Now if I type = new Calculator(); I am allowed to type this without interference, and I see the blue smart tag underline beneath Calculator. A swift Ctrl-. gives me the Generate... menu:

So click on Generate class for Calculator - right? I must admit I already had misgivings before I clicked on this, and this proves to be correct - click on this option and you get a nice fat Calculator class in a Calculator.cs source file and, sadly, inside your CalcLib.Test project, not inside the CalcLib project. This is unfortunate, being as this functionality is in support of TDD, it would have been good to see some intelligence here, ie noting that the current proj is a test project, and has a single reference to another project in the same solution, and at least give us a third option in the menu such as Generate class for Calculator in CalcLib project.

OK, not as good as it should have been. Click on Generate other... instead - this is more long winded, but gives us the flexibility that we are after:

A quick flip of the project menu, press OK, and presto - we now have Calculator.cs in our CalcLib project - is nice. The solution should now build correctly.

Still not much use, because we have an empty test testing an empty class, so lets expand the test firstly by adding a double parameter to the call to the Calculator constructor, thus:

Clicking this gives us a constructor taking a double value as a parameter (albeit it generates a spurious backing property for this parameter, which we don't want in this case - however if it had prompted for a name, we could have added the Total property in one hit, never mind).

Now lets add an assertion that the contructor sets the Total property, and in so doing generate this property in the Calculator class.

If we take the Generate property stub... option and complete the assertion, we now have our test complete and the Calculator class in a compileable state - so lets compile and run the tests. Oops, it doesn't build - the property it generated for us is the wrong type, it can't really infer the type from that overload of Assert.AreEqual, so it has a guess.

Lets try that again, but this time use the generic version of AreEqual so that we know the concrete types for the parameters to this method - hopefully that will allow Generate property stub to correctly guess the type?

Which generates the property as follows:

Much better, so now we CAN compile and run the tests with a Ctrl-R, A and lets see what we get...

Well that sucks - it failed, why? Oh, maybe because we haven't actually implemented the constructor yet - lets do that now.

Now we can build and run the tests one last time -

Great, so we have implemented a test which defines our requirements, observed that the test fails befored the requirement is implemented, and finally observed that once implemented the test passes.

Visual Studio 2010 goes some way towards supporting this method of development, although we have seen a few shortcomings in this beta 1 version. Hopefully at least the issue with generating code within the referenced assembly rather than the test assembly itself can be addressed prior to RTM.

Addendum

Got a great response from Karen Liu, Lead Program Manager on the C# and VB IDE team regarding my questions above, and a quick search revealed some great channel 9 videos she has produced in this same area, especially this one which has the exact same topic as this blog post, and I am embarrased that I didn't spot this beforehand...

Regarding the first issue - the fact that Generate class only generates within the current assembly: the thinking here is that to iterate over referenced assemblies might slow the presentation of the Generate menu, hence the decision was made to only generate within the same class, and refactor later, or to use the Generate other function, as I suggested above.

Regarding the spuriously named property generated with the constructor - Karen had a great suggestion - use a named parameter (C# 4.0 feature), which the Generate constructor function picks up on as expected, so:

Gives us a Calculator class which is already exactly what we need - we don't need to create the Total property in a later step as we did before.

Thanks for the suggestions Karen - looking forward to seeing what we get in the next release!