Visual Studio Hacks [Electronic resources] نسخه متنی

Hack 93. Run Unit Tests Inside Visual Studio

Testing can be just a few clicks away when you
use TestDriven.NET to run unit tests right inside of Visual
Studio.

Test
Driven
Development is the practice of writing unit tests for your code
before you actually write that code. By writing a test and then
writing the code to make that test pass, you have a much better idea
of the goal and purpose of your code. Test Driven Development also
encourages complete code coverage, which not only increases the
quality of your code, but also allows you to refactor the internals
of a method or class and quickly and easily test the outside
interface of the object.

TestDriven.NET
is a unit-testing add-in for Visual Studio. It was developed for a
number of years under the name NUnitAddIn. It now supports multiple
unit testing frameworks and is compatible with all versions of Visual
Studio .NET. It is available in free and professional versions from
the TestDriven.NET web site at http://www.testdriven.net. Its author, Jamie
Cansdale, keeps a web log charting TestDriven.NET's
development at http://www.testdriven.net/

13.3.1. Installing

TestDriven.NET can be installed using an administrator or limited
user account. By default, it will install for just the current user.
Because limited users don't have write access to the
Program Files folder, a limited user installation will install files
in the user's Application
Data\TestDriven.NET folder. An administrator installation
will install files in the Program
Files\TestDriven.NET folder. These defaults can be changed
by selecting Custom on the Choose Setup Type page.

TestDriven.NET is packaged with functional versions of the

NUnit and MbUnit unit testing
frameworks. It also includes an adapter for executing Visual Studio
Team System unit tests when available. These will be installed to
subdirectories inside the TestDriven.NET directory, as shown in Figure 13-2.

Figure 13-2. TestDriven.NET Setup

13.3.2. Run Test(s)

The
Run Test(s) command offers a
straightforward way to build and run tests. It is intended to be the
default method of test execution in most contexts. It automatically
detects the test framework being used and executes tests using the
correct test runner. The tests are launched by a test execution
engine running as an external process. This test process is kept
alive in order to improve execution times on subsequent runs. Once a
test process has been cached, a rocket icon will appear in the notify
box.

If the code editor window is selected, the test(s) to execute will be
determined by the position of the caret. Individual tests are
executed by right-clicking anywhere inside a test method and
selecting Run Test(s), as shown in Figure 13-3. All
tests in a test fixture are executed by right-clicking inside a class
(but outside of any method) and selecting Run Test(s). All tests in a
namespace are executed by right-clicking inside a namespace and
selecting Run Test(s).

Figure 13-3. Run Test(s) menu item

The Run Test(s) option is also found on various Solution Explorer
context menus. It can be used to execute all tests in a solution,
project, or project item.

13.3.3. Ad Hoc Tests

Ad hoc
tests offer a useful alternative to throwaway console applications.
They should not in any way act as a substitute for real unit tests.
Rather, they are intended to provide a convenient way of exploring
local private methods or third-party code.

Any method that does not take parameters
can be executed as an ad hoc test simply by right-clicking inside it
and selecting Run Test(s). It can be a public, private, static, or
instance method. In the case of an instance method, an object will be
created using the default constructor of the class (providing, of
course, that the class has a default constructor). The
Dispose method will be called on any object that
implements IDisposable, once the test has been
executed.

If an ad hoc test returns an argument, the argument will be expanded
to the Test output pane. Complex objects will have their fields and
properties displayed. Enumerable objects will be listed. Primitive
objects will be converted to strings and displayed.

13.3.4. Test Output and Task List

The Test output pane is the window in which
all test results and warning messages appear and is shown in Figure 13-4. Trace and debug information is also sent
there, along with console output and error messages. If all tests in
a project or solution are being executed, the Test output pane will
display only ignored or failed tests.

Figure 13-4. Output Test pane

When a test fails, the name of the test, together with the exception
message and stack trace, is displayed. If code has been compiled with
debugging information, the corresponding portions of the stack trace
will contain line numbers. Double-clicking on these portions is a
convenient way of navigating to the offending code.

As well as sending information to the output pane, failing tests also
get added to the task
list. If many tests have failed, this creates a useful summary view
as shown in Figure 13-5. Generally, the further up
the stack trace, the more likely the code will be of interest.
Double-clicking a test in the task list is an alternative way of
accessing the code in question.

Figure 13-5. Task List view

13.3.5. Test With... Debugger

The Test With... menu

offers many alternative contexts in
which to run tests. Selecting the Debugger context executes test(s)
with the Visual Studio debugger attached, as shown in Figure 13-6. By setting a breakpoint on a method and
selecting Test With... Debugger, it is possible to step
into a unit test.

Figure 13-6. Debugger command on Test With... submenu

By default, Visual Studio will build all
projects in a solution when executing with the debugger. In Visual
Studio .NET 2003 and Visual Studio 2005, there is an option to
"Only build startup projects and dependencies on
Run". Checking this option can significantly improve
startup times when debugging large solutions. In Visual Studio .NET
2003, this option is under Tools Options
Environment Projects and Solutions. In Visual Studio 2005,
it can be found under Tools Options Environment
Projects and SolutionsBuild and Run.

13.3.6. Test Projects and Solutions

By right-clicking on a project in
the Solution Explorer window and selecting Run Test(s), all tests
within that
project
will be executed. Failed and ignored tests are sent to the Test
output pane and task list in a similar fashion to other Run Test(s)
commands. Trace, debug, and console output is suppressed when
executing all tests in a project or
solution.

Similarly, all tests in a solution can be executed by right-clicking
on the solution in the Solution Explorer window and selecting Run
Test(s). For each project in the solution, the test framework being
used is established and tests are executed using the correct test
runner. Projects that do not contain any tests are simply ignored.

13.3.7. Aborting a Test Run

When a test run is in progress, an
Abort Test menu item will appear on the Tools menu, as shown in Figure 13-7. Selecting this item will abort the thread the
tests are executing on. When tests are aborted in this way, any
cleanup logic is given a chance to run.

Figure 13-7. Abort Test command on Tools menu

13.3.8. Stopping the Test Process

You
will sometimes need to stop the test
process. The most common of these circumstances is when an app domain
is created, but not unloaded by a test run. This can result in any
assemblies loaded by the app domain being locked, which causes
subsequent builds to fail. It is possible to recycle the test process
by right-clicking on the rocket icon in the notify box and selecting
Stop, as shown in Figure 13-8. A new test process
will be launched the next time the Run Test(s) command is executed.

Figure 13-8. Stopping the test process

Jamie Cansdale