TestRunner for Visual Studio 2005 Manual

Ways To Run Tests

Since TestRunner is fundamentally about making testing easier through integration, you'll find there a lot of different ways to run tests. Let's break them down by where in Visual Studio you can look.

Text Editor

Inside the text editor, there are two primary ways to run NUnit tests, the context menu, and hotkeys. Both track against the cursor, so that if you are inside a test method, that test will run, and if you are in a test fixture, just outside a test method, but inside the containing class, all the tests on that fixture will run. Within running, you can run or debug.

  • Ctrl-r,t hotkey to run a test
  • Ctrl-r,d hotkey to debug a test
  • Run Test context menu to run a test
  • Debug Test context menu to debug a test

TestRunner Window

The window fills improves upon NUnit-Gui, with the same basic presentation formation. Support for running whole sets of tests, categories, individual test, and navigation is included. There is a toolbar across the top of the window with several features, as well as a context menu for the test tree views.

  • Selected tests are simply marked with a check box
  • Profile, this enables coverage and code profiling data collection.
  • Reload Tests, the refresh icon will reload the tree with a fresh internal NUnit.
  • Run Test Button, the green arrow will run all currently selected tests, filtered by the categories selected. If there are no categories in your code, this button runs all the selected tests.
  • Stop Test Button, the blue box will stop the current test run, acting like a cancel.
  • Solution Mode Toggle, the icon the same as used in the Solution Explorer. This is a toggle that when pressed causes the TestRunner window to load all projects in your solution for tests, and when not pressed only loads the current startup project.
  • Run on the context menu over each test in the tree runs the test.
  • Debug on the context menu over each test in the tree debugs the test.
  • Run All on the context menu over each test in the tree is the same as hitting the green arrow run test.
  • View will take you to the definition of your test in source code.
  • Show Root Error on a failed test will take you to the deepest point in the failure stack trace, which is usually the root cause.
  • Show Top Error on a failed test will take you to the topmost point in a failure stack trace, which is usually the test assertion.
  • Edit Log Text opens a Visual Studio editor window with the output text from Trace and Console capture during that single test case.
  • Clear flushes out all tests from the tree.

TestRunner Window Failed Tests

Most testing is about resolving failed tests, so TestRunner keeps track of failed tests for you and buffers them up in the Failed Tests panel. From here you can do all the things in the TestRunner Window, but conveniently targeted at failed tests.

Solution Explorer

For folks that are file oriented or just generally navigate with Solution Explorer, TestRunner is fully integrated. There are four levels you can run tests from the Solution Explorer.

  • Run Solution Tests from the very root of Solution Explorer.
  • Run Project Tests from the each project node in Solution Explorer.
  • Run Folder Tests from folders within a project in Solution Explorer.
  • Run File Tests from individual source files in a project in Solution Explorer.

Limitation

Directory based web projects don't compile down to a single assembly that can be loaded by NUnit. This generally isn't a problem, as standard practice seems to be placing code in a library project and referencing that from your web site project. However, if you put your unit tests in code behind, or in a web site directory project, they won't be readable by TestRunner.

Recap

TestRunner is there for you, all over in Visual Studio. Working with multiple programmers on a team, there is no right way to use it, and folks seem to go alternate mostly between running in the editor for single tests, and the TestRunner Window for running all tests for a check-in.