Release Notes
NUnit 2.2 - August 8, 2004
General
- NUnit 2.2 is available in separate Microsoft .NET and Mono distributions.
The .NET version can run under Microsoft .NET 1.0, 1.1 or 2.0. The Mono
version runs under Mono 1.0. The Microsoft distribution is built using
Visual Studio 2003. The Mono version is limited to use of nunit-console
to run tests. Note that Mono is distributed with a version of NUnit
pre-installed. It may be necessary replace some of the installed
components in order to get a newer version of NUnit to work. A note
will be published when we have more information on this issue.
- Separate config files for each .NET version are no longer needed. Instead,
binding redirects are provided in each config which apply when running under
version 1.0 or 2.0 of hte .NET framework. By default, the highest level of
the framework installed is used. The user may edit the config file if a
different preference is desired.
- The NUnit framework and core are now in separate assemblies, both of
which are installed in the GAC. The framework assembly contains all
types that are normally referenced by tests, while the core contains
those types used by the gui and console runners to execute those
tests. Tests requiring use of core types – TestSuite, for example –
will need to add a reference to the nunit.core.dll assembly.
- The NAnt build script now supports building NUnit using version 1.0, 1.1
or 2.0 of the .NET framework or with Mono 1.0. The Mono build is limited
to those assemblies used under Mono.
- Assert.AreEqual has been extended to allow comparison of two arrays.
To compare as equal, the arrays must be of the same or compatible types,
contain the same number of elements and each pair of elements
must compare as equal.
- All Assert methods that take an optional message argument now also may
take an optional array of objects to be used in formatting the message.
- An Assert.Ignore method has been added, which allows individual test
cases to be ignored dynamically - for example, on the basis of products
installed on the test system. Assert.Ignore may also be called from a
SetUp or TestFixtureSetUp method. In the latter case, all the tests are
ignored.
- Failure in TestFixtureSetUp or TestFixtureCleanUp now results in an error,
rather than in ignoring all the tests.
- The core interfaces used to run tests have been changed substantially.
These will continue to change to some extent as we attempt to reach a
stable set of interfaces for use by third-party clients that run tests
through NUnit. In particular, the interfaces now support passing in an
array of tests to be run and return an array of test results. Other
new features described in this document have required interface
changes as well.
- There is a new CategoryAttribute which allows test fixtures and methods
to be grouped into one or more categories using strings as identifiers.
Support is provided for running only those tests in selected categories
or all tests except those in selected categories.
- A new ExplicitAttribute designates a test case or fixture that should
only be run when explicitly chosen by the user - selected directly or
included by means of a Category selection. It will not be run merely
because its parent suite is selected.
- Tests may now be run using a filter. Currently, this support is used
only by the new Category feature, but it is intended to be of general
application for clients and – eventually – users.
- NUnit now recognizes when the loaded tests were built using an earlier
version of the nunit framework and issues an appropriate message.
Earlier versions simply failed to show any tests present in the assembly.
- NUnit now captures and issues a message when a worker thread, created
during the running of a test, throws an exception. Previously, such
exceptions were silently ignored.
- The XML output from a test run now shows the number of Asserts executed
by each test.
- When a test with ExpectedException fails because of an Assert, the
message from the assert is now given priority over the message
indicating that the wrong type of exception was thrown.
- Private SetUp and TearDown methods are now ignored as intended.
- SetUp and TearDown are no longer executed for ignored tests.
- The documentation is now provided as a set of HTML files.
Forms Interface
- The tree of tests now optionally displays checkboxes. These may be used
to select multiple tests to be run. Buttons allow clearing all checkboxes
and checking only failing tests.
- There is now an option to display the name of each test in the standard output.
- The thread used to run tests is now created in the test AppDomain. The
priority and apartment state for this thread may now be specified in
the config file for the test. A separate configuration section is now
used for NUnit settings, to avoid name collision with settings required
by the application under test.
- Command-line options are provided to allow the gui to load and begin
running a test suite and to load a specific fixture from an assembly.
The properties dialog now shows the number of asserts executed for
each test and any description associated with a test.
- A cancel button has been added to the project save dialog that appears
on shutdown.
- The display of the last exception is now scrollable, allowing the
entire stack to be seen.
Console Interface
- The console program has been reorganized to remove differences in how
tests are run between the console and gui runners.
- The console interface command line parameters now include provision for
selecting or excluding tests based on category, for displaying the name
of each test in the standard output and for redirecting standard or
error output from tests to a file.
- The /noshadow option eliminates creation of a shadow copy and the /thread
option causes the console tests to be run on a separate thread. When a
separate thread is used, the config file settings for apartment state
will be honored.
- A namespace may now be specified after /fixture and all tests in that
namespace will be executed.
Mock Objects
- This version of NUnit comes with a built-in, lightweight mock object
facility. The functions provided include dynamic creation of an
implementation of any interface or MBR class, setting of expectations,
specification of return values and verification that the expected
actions occurred.
- This facility is in no way a replacement for full-fledged mock
frameworks such as NMock and is not expected to add significant
features in upcoming releases. Its primary purpose is to support
NUnit’s own tests. We wanted to do that without the need to choose a
particular mock framework and without having to deal with versioning
issues outside of NUnit itself.
- At the same time, we hope that easy availability of a minimal mock
object facility will inspire users who are not familiar with mock
objects to experiment with them using our built-in facility and to
migrate to a more complete framework as your needs call for it.
Limitations
- The CategoryAttribute was originally designed to have an Explicit
property. This was included in some early releases and is described in
the Pragmatic Programmers’ recent book. This property has been removed
and is replaced by the ExplicitAttribute, which can be used in
conjunction with Category to achieve the same effect as shown in
their examples.
NUnit 2.1 - September 1, 2003
General
- The distributed version of NUnit 2.1 is now built using Visual Studio 2003 The solution and
project files in this Beta can only be loaded by Visual Studio 2003. Those needing to build
with Visual Studio 2002 will need to convert the project, solution and resx files.
NUnit can run against .NET framework versions 1.0 or 1.1. Separate config files are provided for
using either version. The install detects the highest version installed and sets up the config for
that version.
- NUnit now supports loading and running tests across multiple assemblies in both the console and
the GUI. This may be done on an adhoc basis or by creating NUnit test projects saved in files
of type NUnit.
- Information about one or more test assemblies may now be persisted as NUnit Test Projects.
This is a file of type .nunit in XML format which supports the definition of multiple
configurations each containing one or more assemblies.
- TestFixtureSetUp and TestFixtureTearDown attributes are now recognized. Methods marked
with these attributes will be run before and after the tests in a fixture. Unlike the standard
SetUp and TearDown attributes, these methods are invoked only once, before and after all the
tests are run.
- The Assertion class is now deprecated and has been replaced with the Assert class supporting
a new set of static method names.
- The reporting of test failures and errors provides more information. The specific type of an
exception is reported as well as any inner exceptions. Exceptions in TearDown no longer hide
the original test exception.
- NUnit now runs under Windows 98 and ME. Automatic reload of changed assemblies is
disabled in non-NT environments.
Forms Interface
- There are a number of additional menu items. [Specify]
- The GUI interface now runs tests on a separate thread. This allows the tree display to update as
execution proceeds. A Stop button now allows cancelling a test run. An option to cancel the
run is also displayed if the user attempts to exit while a test is running.
The GUI test threads run in the MTA by default. A configuration file setting may be used to run
them in an STA.
- XML output from a test run may now be saved using the Tools | Save Results as XML… menu
item. The format is the same as that used by the Console runner.
- When an exception occurs while trying to load, unload or run a test, the complete stack trace for
that exception is available through the Tools | Exception Details… menu item.
- The Tools | Options… menu item allows setting a number of options. [Specify]
- Automatic reloading of test assemblies may now be disabled. An alternate approach of reloading
assemblies whenever a run begins is also available as an option.
- If Visual Studio support is enabled, Visual Studio project and solution files may be opened and
Visual Studio projects may be added to an NUnit test project. Currently, C#, VB.NET, J# and
managed C++ projects are supported.
- When a Visual Studio or NUnit project is loaded, the user may switch between the available
configurations causing the tests to be reloaded. A Configuration Editor allows adding,
deleting or renaming configurations.
- The GUI allows creating and modifying NUnit Test Projects through the Project Editor.
A Properties window is now availble to display information about any test in the tree. It may be
pinned to allow quickly examining the results of different tests.
- Window layout has been streamlined, eliminating one splitter and reducing the area above the
tabs to the minimum size needed.
- The File | Recent Assemblies menu item is now called Recent Files since it may hold Visual
Studio or NUnit project names. The user may now set the number of items kept in the list.
- Loading of the most recently used file may be disabled by a command line switch.
- Nested Classes are now shown in the TreeView using the format OuterClass+InnerClass.
[Showing InnerClass under OuterClass was confusing when both classes contained tests.]
- The contents of the TreeView display are now sorted by name and tests execute in the order of
the display to allow easier tracking.
- Splitter positions are now saved in the registry and restored on startup.
- A View menu includes options for Expanding and Collapsing tree nodes, including Expand All,
Collapse All, Expand Fixtures and Collapse Fixtures.
Console Interface
- The console interface command line parameters have been modified to support loading of
multiple assemblies, Visual Studio projects and NUnit projects. Several new switches are
available. See the Command Line Parameters section in this document for details.
- The console runner and tests now run in an STA.
- When run in debug mode, the console output is now sent to the Visual Studio Output window.
- Clicking on a test failure brings up the test file in the editor at location of the Assert.
Formatting of console output has been improved so that redirected output may be examined
conveniently in an editor that requires CRLF at the end of each line.
- All errors are now trapped and a message is displayed.
Limitations
- NUnit can only load assemblies as permitted under .NET’s Code Access Security. Using the
default settings, this means that you will be unable to load from any UNC path, including one
that specifies the name of the local computer. Although you may use the .NET Framework
configuration utility to allow loading of such applications, you must do this with care. Often,
the simplest approach is to copy assemblies being tested to your local drive.
See Visual Studio Support for limitations on loading Visual Studio solution files.
NUnit 2.0 - October 3, 2002
General
- Attribute based mechanism for identifying test fixtures and test methods. In previous versions of
NUnit and JUnit for that matter, inheritance was used as the mechanism for identifying which
classes were test fixtures and a naming convention was used to identify test methods in these
classes. The Custom Attributes available in .NET provide a much more straightforward and less
ambiguous mechanism for identification.
- Automatic creation of test suites. In previous versions of NUnit it was required to manually
construct suites of tests using a Suite property. This has been replaced with dynamic creation of
suites based on namespaces. Given an assembly the program will search through the assembly
looking for test fixtures. Once it finds one it creates a suite based for each namespace and the
specific test fixture. For example, NUnit.Tests.SuccessTests will build a containing Suite
called “NUnit” which will contain another suite called “Tests” which in turn will create another
suite called “SuccessTests” which finally will hold the individual test methods. This corrects an
error prone task where things may or may not have been included in a suite.
- Additional samples, Managed C++ and Visual J#. The existing samples (C#, VB.NET, Money)
have been upgraded to the new version. Money-port has been included to demonstrate the
minimal amount of effort required to upgrade.
- A class TestCase in nunit.framework.dll has been provided for backwards compatibility.
See the “Money-port” project as a sample of what is required to upgrade to the new version. The
only change is to update the reference to the new framework dll and provide a default constructor.
- The exception that is thrown when an Assertion fails is now called AssertionException. In
previous versions this was called AssertionFailedError.
Forms Interface
- Tree based display in forms interface with test status indication and the ability to run
individual tests or suites from the tree.
- Dynamic reloading of an assembly using AppDomains and shadow copying. This also
applies if you add or change tests. The assembly will be reloaded and the display will be
updated automatically. The shadow copies use we use a configurable directory specified
in the executable’s (nunit-gui and nunit-console) config files.
- A reload command menu option to load and assemblies that may have been modified.
- Window sizes are flexible due to the introduction of splitters on major sub-areas of the
screen.
- File->Recent Assemblies menu item. The program keeps track of the 5 most recently
used assemblies. If no command line arguments are used to start the forms executable
the most recent assembly is loaded by default.
- The “Run” button is the default button on the form, which allows hitting return to start
the tests.
- Patches suggested by Al Gonzalez
- The AboutBox was modified so its start position is set to CenterParent
- The AboutBox border was changed to Fixed3D
- The size and position of the main form is saved in the registry and restored when the
program is launched
- Patch suggested by Rob Jeffries
- When the main form has the focus hitting the space bar will cause the program to
exit. This is present in the current version of the VBunit.
Console Interface
- The console interface command line parameters have been modified to be more explicit and
conform to similar programs available in .NET. See the Command line parameters section
in this document for details.
- XML Output. The console program produces XML output suitable for inclusion into other
existing systems.
- Customizing of console output is provided through the use of XSLT. See Summary.xslt for
the translation that is provided for the release. Using your own transform file is possible via
a command line argument.
- Backwards compatibility with running suites. The Forms interface currently has no
mechanism to run suites defined with the suite property. Using the fixture command line
argument you must specify a class that is either a TestFixture or contains a Suite attribute.
