1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
Release Notes for NUnit 2.2 Final Release
August 8, 2004
This is the fourth major release of NUnit and the third since it was
rewritten to take advantage of .NET custom attributes. Highlights of
this release include support for Mono, multiple-test selection in the
GUI interface, a built-in lightweight mock object facility, new
command line switches for both GUI and Console runners, and new
Category and Explicit attributes.
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
NUnits 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.
|
