I use Visual Studio 2008 in combination with MSTest to do Test Driven Development. One of the most important and frequent tasks when practicing TDD is running your tests. Much has been said about NUnit’s better fit with TDD (in great part due to their standalone test runner that simply re-runs all your tests when the assembly is rebuilt), but it doesn’t have to be as bad as it may be out of the box with only a few tricks and tweaks to Visual Studio.

Firstly, it’s extremely important to know your keyboard shortcuts. It always amazes me when I see developers write a whole bunch of code using both hands on the keyboard and then reach for the mouse to click the green Play button to run it. Ctrl-F5 runs your code, F5 debugs it; it’s that simple. With TDD, however, there is another step between writing and running your code. It is running your tests. Visual Studio’s approach to test management is very QA oriented, but it does have the simpler commands for running tests within the current context as well as ALL tests and they have keyboard shortcuts defined by default. Here they are and they all perform a build first if necessary as well:

Note that these in fact are keystroke macros and mean that you first press Ctrl-R and then press A by itself.

Sometimes, a complete rebuild is required to flush old binary artifacts and this by default requires going into the menus. Ctrl-Shift-B shortcut builds the solution so I find it useful to map Ctrl-Alt-Shift-B to the Rebuild Solution command. You can do this easily from the Tools->Options Menu:

Click to enlarge

Finally, the test-runner window could become cluttered with test results once the number of tests increases significantly. This makes finding the failed test somewhat painful. If you look at the 4 possible Result values for the tests—Pending, In Progress, Failed, and Passed—you may notice that all but Passed have an ‘i’ in them and we only care about tests that don’t pass. So if you filter the Test Result window to only show tests with an ‘i’ in the Result you get a list of all tests in Progress or Pending but which filters out the successful tests and leaves only the Failed ones behind after the test run is done.

Click to enlarge

Unfortunately, the filter setting doesn’t stick between VS restarts and you have to repeat the process but it’s quick and simple.

With these settings I find writing and running tests a breeze in Visual Studio.  These suggestions will work in Visual Studio 2005 as well although VS 2005 test runner’s performance issues are a mroe difficult issue to overcome.