GUI

Well, now it's time to run your first Nunit test. When you install Nunit you get two choices on how to run your unit tests: Either a GUI based version of the Nunit test runner, or a console based one. The Gui one is located in Start->Programs->Nunit V2.1->Nunit-Gui . When you open it you get a pretty “not beautiful” but very functional interface that allows you to select an assembly with compiled unit tests inside it and run all the tests that are there.

• Select File->New project
• Select Project->Add assembly and select your compiled tests assembly.

Once you've selected your assembly you'll see the tree on the left fill up with namespaces, with the names of any test fixtures inside them and the names of any tests inside them. Now you can see why it's important to put those attributes on our classes and tests. It's how we make out testing GUI find them and run them.

Make sure the top node of the tree is selected and click “Run” on the right side of the form. You see the progress bar very quickly turn green to signify success. If the bar is red, it means that test has failed and you can go back and make it succeed.

I won't go into too much detail here on how to use all the features in the Nunit GUI but you can learn all you need by reading the documentation for it. Feel free to close the GUI, it will remember the last assembly you loaded in it next time. On important thing to note here is that once one test inside a test suite fails, all other tests will not run.

Console

Besides the GUI version of the Nunit test runner, you also get a Console test runner. This is especially good for when you have an automated build procedure that runs unattended. You can make it call the console version of Nunit which outputs directly into the stdOutput and have it log all results.

To make the console do the testing, you need to switch to [Nunit program files folder]\Bin . From there you can run Nunit-Console.exe providing the name or full path of the assembly to test against. I urge you to put that path inside the global PATH environment  variable so that you can use the console easily from anywhere.

More testing goodies we get

• Another attribute you can put on a test is the [Ignore(reason)] attribute, Use this to skip certain tests , but the reason for their skip will be displayed inside the GUI.
• You can have a [Setup] and [TearDown] method inside your fixture. The [Setup] runs before each test in the current fixture is run, and the [TearDown] runs after each test.  These methods are very useful for when you want all your tests to use the same set of clean initialized data. In there you can initialize global variables, delete or create  needed files and so on. This of [Setup] as an implicit contructor for each test, and of [TearDown] as a destructor for it. Methods that are marked by these attributes should not be marked as tests as well!
• You can have a [ TestFixtureSetUp ] and [ TestFixtureTearDown ]  methods as well. These methods will be run only once for each test fixture tested. Use them for global initialization and cleanup of resources that can be shared by all tests in that fixture.
• Another excellent attribute we get is the [ExpectedException] attribute. When a test method is decorated with this attribute and no exception of the type specified in the attribute is thrown inside the test, thw test has failed. This is perfect to check that your components throw exceptions at the right moment, such as bad user input and so on. We'll use this attribute to add another test to our fixture, which test for the CalcException:
  
  [Test]
[ExpectedException(typeof(CalcException))]
public void  TestException()
{
      int retVal = calc.Add(null,22);
      Assert.IsTrue(true);
}

As you can see it couldn't be easier.