Professional Documents
Culture Documents
Introduction
In this document, we will review about open source unit test tool Nunit.
NUnit is an open source unit testing framework for Microsoft .NEt. It serves the
same purpose as Junit does in the Java world, and is one of many programs in
the xUnit family.
Initially ported from Junit, the current production release, version 2.6, is the
seventh major release of this xUnit based unit testing tool for Microsoft .NET. It
is written entirely in C# and has been completely redesigned to take advantage
of many .NET language features, for example custom attributes and other
reflection related capabilities. NUnit brings xUnit to all .NET languages.
Nunit Official Website: http://www.nunit.org/
The primary goal of unit testing is to take the smallest piece of testable
software in the application, isolate it from the remainder of the code, and
determine whether it behaves exactly as you expect. Each unit is tested
separately before integrating them into modules to test the interfaces between
modules. Unit testing has proven its value in that a large percentage of defects
are identified during its use.
Conduct the code execution tests defined in the Unit Test Plan using dynamic
analysis techniques. Automated dynamic analysis tools can be used to assist
with this process, (e.g., code coverage monitors, memory analysis tools, in
addition to analysis features available with application development
environments, such as Visual Basic by Microsoft Corporation).Test program
units one at a time. This approach makes the identification of errors easier,
because there are fewer places to look for problems.
Program units are tested immediately after coding of the unit is complete, which
means the modules(s) the unit interfaces with may or may not be available. To
test the receipt of input data, it may be necessary to use temporary modules that
simulate the real modules.
A driver module is used to simulate a calling module and call the program unit
being tested by passing input arguments. The driver can be written in various
ways, (e.g., prompt interactively for the input arguments or accept input
arguments from a file).
To test the ability of the unit being tested to call another module, it may be
necessary to use a different temporary module, called a stub module. More than
one stub may be needed, depending on the number of programs the unit
calls. The stub can be written in various ways, (e.g., return control immediately
or return a message that indicates it was called and report the input parameters
received).
After conducting the test, compare the actual result to the expected result. If
there is no difference, record the test as non-discrepant on the Program Unit Test
Plan. If there is a difference, record the discrepancy on the Program Unit Test
Plan, and determine if the discrepancy is the result of an error in the code or an
error in the expected result.
If the expected result is in error, correct the expected result, and rerun the test.
When all tests have been executed and errors corrected, re-execute the full unit
test to ensure that no new errors were created during error correction. Record
any metrics as required by the unit test procedures, (e.g., the types of errors,
such as error handling, failure to reinitialize, the number of errors found, the
number of lines of code, and the number of interfaces). Use evaluating test
metrics to identify methods for gathering test metrics.
Nunit
NUnit is an evolving, open source framework designed for writing and running
tests in Microsoft .NET programming languages. NUnit, like JUnit, is an aspect
of test-driven development (TDD), which is part of a larger software design
paradigm known as Extreme Programming (XP). It is written entirely in C# and
has been completely redesigned to take advantage of many .NET language
features, for example custom attributes and other reflection related capabilities.
Test cases
Text fixtures
Creating a test
Running a test
Test Cases:
A test is the lowest building block of unit testing and tests a single piece of
software functionality. Programmatically, a test corresponds to a method in the
unit test code.
You identify a test by decorating a method with the [Test] attribute. For example
[Test]
public void Test1( )
{
// test case implementation
}
A test method must be public (so that the test runner can locate it using
reflection), returns void, and take no arguments. A unit test performs one or
more assertions that determine whether the functionality being tested works
properly. An assertion simply tests an actual post-condition against the expected
post-condition required for the test to pass.
The [Test] attribute has an optional argument named Description that defines the
description that appears in the test properties dialog in the test runner GUI. For
example:
[Test (Description = "MyTest")]
Test Fixtures:
A test fixture is used to group and run multiple tests that test a logical collection
of functionality. Programmatically, a test fixture corresponds to a class that in
turn contains unit tests as methods of the class.
A test fixture class must have either a public default constructor or no
constructor, which implicitly creates a public default constructor. Identify a
class as a test fixture by decorating it with the [TestFixture] attribute. For
example:
[TestFixture]
public class Class1Test
{
// test fixture implementation
}
In addition to unit tests, a test fixture contains any setup and teardown code for
both the test fixture and for the tests within the test fixture. Setup and teardown
code is optional.
Creating a Test:
The following steps outline how to create a solution that contains two projects
a project being tested and an NUnit test project:
1. Open the Visual Studio .NET IDE and create a new blank solution
called NPR.
2. Add a new Visual C# class library project called MyApp to the solution. This
is the project youll be running the tests against.
3. Rename Class1 to MyMath. Change the class declaration to read:
public class MyMath
4. Add a single method called Add that takes two integer arguments and returns
their sum. The completed class follows:
using System;
namespace MyApp
{
public class MyMath
{
public int Add(int i, int j)
{
return i + j;
}
}
}
5. Add a new Visual C# class library project called MyAppTest to the solution.
This is the project that will contain the NUnit tests. It is a good idea to use a
name that allows the test project to be easily identifiedfor example, use the
name of the project being tested with the suffix Test.
6. Add a reference to the NUnit framework to the test project MyAppTest; select
Project->Add Reference from the Visual Studio .NET IDE menu. In the Add
Reference dialog, double-click on nunit.framework in the listbox on the .NET
tab and click OK. (See Figure 3.)
using NUnit.Framework;
10. Add the MyApp types to the test class Class1:
using MyApp;
11. Add the [TestFixture] attribute to the test class Class1 to indicate that the
class contains test code. So far we have:
using System;
using NUnit.Framework;
using MyApp;
namespace MyAppTest
{
[TestFixture]
public class Class1
{
}
}
12. Create test method MyAddTest in the test class. Remember that this method
must be both public and void, and take no arguments. Identify the test method
by decorating it with the [Test] attribute:
[Test]
public void MyAddTest( )
{
}
13. Write the test. In this case, test the Add method in MyMath:
[Test]
public void MyAddTest( )
{
MyMath m = new MyMath( );
Assert.AreEqual(m.Add(2, 3), 5);
}
The completed test class follows:
using System;
using NUnit.Framework;
using MyApp;
namespace MyAppTest
{
[TestFixture]
public class Class1
{
[Test]
public void MyAddTest( )
{
MyMath m = new MyMath( );
Assert.AreEqual(m.Add(2, 3), 5);
}
}
}
14. Compile your code.
15. Run the test as described in the next section "Running a Test" (open the test
assembly MyAppTest.dll in the NPR\ MyAppTest\bin\debug directory from the
test runnerGUI). Figure 6 shows the test runner GUI after running the test.
Running a test:
The test runner is an application that locates tests within an assembly, runs
them, and organizes the test results. NUnit provides both GUI and console test
runners.
The NUnit test runner executes each test once. Before executing each test, testlevel setup code is executed. After executing each test, test-level teardown code
is executed. SetUp and TearDown are described later in "Other Testing
Elements."
The following steps outline how to run tests using the test runner GUI:
1. Launch the NUnit test runner GUI.
2. Click FileOpen and select the DLL built by the test project. In our
example, this is MyAppTest.dll in the bin\ Debug folder for the project.
3. The test runner GUI displays all test fixtures, and the tests each fixture
contains are visibile in the tree in the left pane.
4. To run all tests, select the topmost node in the tree view. Alternatively, to run
a subset of tests or a single test, select any node in the tree view.
5. Click the Run button. If the tests pass, a green bar will display; otherwise, the
bar will be red. Colored dots next to the tree view nodes indicate the success or
failure of tests, test fixtures, and test suites.
Advantages of Nunit:
Disadvantages of Nunit:
Hundreds of small tests or a few Large Tests?( a common mistake that
most developers do is to take the word unit to literally and set about
writing 100 of tests for 1 module. Although sound in theory it is madness
in practice. So the developers run out of the time and the final result is a
stack of useless tests)
Nunit can really stress developers out ( this is a serious problem when
developers are under the gun to meet deadlines and an n unit test breaks
the cruise control build. So everyone knows that the development should
be stopped until the build is fixed. But most of the developers will ignore
and start working on something else)
C based extensions not available(extensions are not available to c
language
Lack of awareness among .Net Community
The program is unstable in certain situations.(kept under certain
situations, or based on different platforms, nunit can be unstable)
My insight on Nunit:
In my opinion NUnit is a lot better than other open source tools out there for
unit testing. NUnit is very stable, fast, well supported and documented and
supports many of the use case scenarios that you would typically use day to day.
Although MSTest beats it in terms of IDE integration even without the new Unit
Test Adapter it is still very easy to setup and use; the fact that the GUI runner
automatically reloads assembly changes means you can have an almostcontinuous test setup.
References:
http://en.wikipedia.org/wiki/NUnit
http://en.wikipedia.org/wiki/Unit_testing
http://stackoverflow.com/questions/652292/what-is-unit-testing-and-how-doyou-do-it
http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.aspx
http://blog.codinghorror.com/good-test-bad-test/
http://code.tutsplus.com/articles/the-beginners-guide-to-unit-testing-what-isunit-testing--wp-25728
http://it.toolbox.com/blogs/enterprise-solutions/conducting-unit-testing-17287
http://tutorials.csharp-online.net/Unit_Testing_with_NUnit
%E2%80%94Test_cases
http://blog.codinghorror.com/good-test-bad-test/
http://code.tutsplus.com/articles/the-beginners-guide-to-unit-testing-what-isunit-testing--wp-25728