Freigeben über

Test-Driven Development With Test Lists

  • Artikel

For most of the time, I write code using the test-driven development methodology. This means that I write a bit of code, run a suite of tests, write a bit more code, run some more tests, etc. For this reason, I need unit testing to be an integrated part of my development experience: It should be integrated with Visual Studio and readily available.

Before Visual Studio 2005 Team System, I used NUnit for unit testing. It actually worked pretty well: Usually, I hooked up the Visual Studio debugger to launch the NUnit GUI, so whenever I wanted to run a test suite, I just pressed F5. That would launch the NUnit GUI with all the appropriate tests loaded and I just had to hit Enter to make it run. NUnit could use an XML-based configuration file, so I could define a test suite from multiple tests projects. The hierarchical nature of NUnit's test lists made it easy to run only relevant tests at times when I wanted to narrow down my focus a bit.

When I first began using Visual Studio 2005 Team System, I have to admit being a bit disappointed with the user interface. Although I could see a list of my tests integrated in the IDE, there was a lot of mouse-clicking involved in running tests. For test-driven development, this seemed rather clunky, but I decided to give it a chance, since James Newkirk (one of the original NUnit authors) had been involved in the unit testing features of Visual Studio 2005 Team System - this suggested to me that the different UI approach wasn't necessarily a result of ignorance on the VS team's part.

As I expected, I have slowly evolved a different way of working with the Visual Studio Test Lists when doing test-driven development. Here's how I handle the different challenges:

  • How to avoid excessive mouse clicking: First, I switch to the Test Manager window (if you don't have Visual Studio 2005 Team Edition for Software Testers or Team Suite you can use the Test View window instead) using the keyboard combination Alt+s, w, m. Once there, I select the tests I want to run and run the tests. There's no direct keyboard shortcut for running or debugging the selected tests, but as Sara Ford has been so kind to point out, you can access the tool window toolbar by pressing Shift+Alt.
    So, to run a list of already selected tests, I press Alt+s, w, m, Shift+Alt, Enter. Granted, it's a bit more cumbersome than pressing F5, Enter, but after doing this a lot, I can do it pretty fast. It still seems like a change to the worse, but the test list offers a few advantages that make up for this.
  • Running all tests: Running all loaded tests is pretty easy - once in the Test Manager window, you just need to move the focus to the All Loaded Tests option and hit Space. Once you have done this, you don't have to change the list until you want to run a different set of test cases (in Test View, you can select all tests by pressing Ctrl+A; it's actually simpler than focusing on the All Loaded Tests option, but on the downside is that you need to do it every time you want to run all tests in the list).
  • Selecting which tests to run: This is where the test lists really come into their own. In NUnit, due to the hierarchical arrangement of tests, you could only easily select a subset of tests if that subset belonged to the same branch of the tree. Tests lists, on the other hand, can be filtered any way you like: You can filter on the test name, the test class, project, namespace, and many other columns, and you can use wildcards. This makes it easy to run only a suite of tests that relates to what you are currently working with.
    Imagine that you are working with a feature called MyFeature. If this word occurs consistently in your test names, you can filter the list on Test Name and set the filter to *MyFeature*. This will give you all the test cases where this string occurs, event across different test projects.
    This feature is what really saves the day for me. Even though I strive to keep my tests efficient, when you have hundreds of tests, you sometime want to temporarily narrow down the list while troubleshooting some particular feature.
    Keep in mind that the tool window toolbar (where the filter UI lives) is accesible via the Shift+Alt keyboard shortcut, and then filtering is only a few Tabs away.

Test-driven development with Visual Studio 2005 Team System is not like using NUnit, and while I'm not saying that it's better, I also don't think that it's worse - it's just different.

Update: If you are an international user (like me), you may experience that the Shift+Alt keyboard shortcut doesn't work. That's because this keyboard combination is also used in Windows to change keyboard layout (e.g. on my machine, it would change from Danish to English, and vice versa). Since I only find it counter-productive to suddenly find myself typing on an English keyboard (when I expected a Danish layout), I always remove the English keyboard.

This has worked well on Windows XP, but it turns out that it's not enough on Windows Vista. However, you can still get the shortcut to work in Visual Studio: Go to the Control Panel and click on Change keyboards or other input methods. On the Keyboards and Languages tab, click the Change keyboards button. In the Text Services and Input Languages dialog, select the Advanced Key Settings and assign another hot key for the Between input languages action. The shortcut should now work in Visual Studio.

Comments

  • Anonymous
    September 18, 2006
    Can you provide more details of how you setup VS to work with NUnit?
  • Anonymous
    September 19, 2006
    Grant Holliday on OzTFS.com Launched.

    Buck Hodges on VC API: CheckIn() may return 0.

    Martin Woodward...
  • Anonymous
    September 19, 2006
    The comment has been removed