You are on page 1of 13

Review of Nunit

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:

Overview of Unit Testing

Unit testing Unit testing is an automated framework for testing, it refers to
testing of certain areas or functions of the code. This gives the ability to know
that the tested code works as it is expected, which means that for any inputs the
code/function returns proper values and also fail to perform when an incorrect
input is provided.
The Microsoft Developer Network (MSDN) defines unit testing as

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.

Why Unit Testing?

The real value behind unit testing is that it forces to stop and think about
testing. Rather than just a general ad-hoc process, it turns into a series of hard,
unavoidable questions about the code that has been written.

How do I test this?

What kinds of tests should I run?
What is the common, expected case?
What are some possible unusual cases?
How many external dependencies do I have?
What system failures could I reasonably encounter here?
Unit tests may not guarantee the exact functioning of a program. I think it's
unreasonable to expect them to. But writing unit tests does guarantee that the
developer has considered, however briefly, these truly difficult testing
questions. And that's clearly a step in the right direction.

Steps To Perform Unit Testing

The process of performing the unit test involves several steps, which are
Review program unit
Conduct the code execution tests
Identify and resolve any discrepancies
Determine that test is complete

Review Program Unit

Perform a review of the program unit using static analysis techniques (e.g.,
a desk check, inspection, or structured walk-through), before running the
program to test the program unit. Automated static analysis tools can be used to
assist with this process.

Conduct the Code Execution Tests

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.

Use of Drivers and Stubs

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

Identify and Resolve Any Discrepancies

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 code is in error, use the debugging technique to:

Isolate the cause of the error,
Correct and recompile the program,
Retest the program.

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.

Determine the Test is Complete

The unit test is complete when you:

Finish executing the tests itemized in the Program Unit Test Plan,
Are satisfied the code matches the design,
Finish correcting and retesting identified errors,
Document the test results in the Program Unit Test Plan.

Procedure for Unit testing

Unit testing can be performed in two ways
1. Manually: A manual approach to unit testing may employ a step-by-step
instructional document, Which is not user friendly
2. Automated Frameworks: Using an automation framework, the
developer codes criteria into the test to verify the unit's correctness, they
are most often third party products.
Many more

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.

Nunit Unit Testing:

Performing unit testing with Nunit involves 4 stages:

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

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
[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

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.)

Figure 3. Add a reference to NUnit framework

7. Add a reference to the project being tested: MyApp to the test
project MyAppTest. Select Project->Add Reference. In Figure 3. Add a
reference to NUnit framework the Add Reference dialog, select the Projects tab.
In the listbox, double-click on the project you are testing. Click OK. (See Figure

Figure 4. Add an NUnit project reference

8. The Solution Explorer now appears as shown in Figure 5.
9. Add the NUnit.Framework types to the test class Class1:

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
public class Class1

Figure 5. A Solution Explorer with references

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:
public void MyAddTest( )
13. Write the test. In this case, test the Add method in MyMath:
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
public class Class1
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.

Figure 6. An NUnit test runner GUI results

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
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
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:

NUnit is Open Source and highly extensible.(It is for Free, and is

extensible to different languages
Platform independent.( Can be used on multiple platforms
Simple and easy to learn syntax.( no complex cods or syntaxes to make
things complicated
Zero Defects can be the norm( every time when a complex code was
delivered with 0 defects it suggests that 100% coverage is done for
most complex pieces. With n unit we can get a stable code and we can
also redesign working code to be more maintainable and still release
with almost 100% stable code. redesigning for maintainability is not
practical without a suite of automated tests because it normally
requires a complete rewrite)
It supports multiple language support.( can cater to most people in the
world in their known languages, which make things easily apporachable

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
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.