NUnit – Writing your first Unit Test

If you don’t know what NUnit is, please read this:

NUnit – A Tool for .NET You can’t live Without!!!

If you know what NUnit is, here’s a quick, getting started guide:

According to TDD mantra, you should write your unit tests first (I never do, but I have to repeat that anyway).  Here’s a sample test suite:

Code Snippet

  1. using System;
  2. using System.Collections.Generic;
  3. using System.Linq;
  4. using System.Text;
  5. using NUnit.Framework;
  6. using net.CSharpner.Stacks.DAL;
  7. using Stacks.NUnit.Properties;
  8. using System.Web.Security;
  9. namespace Stacks.NUnit.DAL
  10. {
  11.     [TestFixture]
  12.     public class StackClassTestsClass: BaseTestClass
  13.     {
  14.         [Test]
  15.         public void CreateStackTest()
  16.         {
  17.             Assert.Fail(“Not yet implemented”);
  18.         }
  19.     }
  20. }

My example:  I created a DAL (Data Access Layer) for a small, Windows application I’ve written.  The DAL is a simple class wrapper to let me read and write to some tables in a database.  Pretty straight forward stuff.  I need automated tests to validate my DAL.

My automated tests will consist of a simple .NET class with one method for each test.  I added a class library project to my solution and made just a plain old simple .NET class.  You should have noticed there are two attributes I’ve decorated my class and my one method in the class with:  [TestFixture] and [Test].  These two attributes come from the NUnit.Framework namespace (notice that I have a using statement to use that namespace.  Not pictured here, I’ve added a reference to the nunit.framework.dll from the NUnit application folder under “Program Files”.

The attribute [TestFixture] simply tells the framework (and the GUI or console based test program) that this class should be loaded and used as a test suit.  Next, I put [Test] above each method in my TestFixture class that I want to be treated as an individual unit test.  Not all methods in my class have to be a [Test]… just the ones I want executed during the automated test run.

Notice the name of the one method in my short, sample test suite:  “CreateStackTest()”.  One of the tables in my database is called “Stacks” and one of the classes in my DAL is a simple wrapper for that table.  This CreateStackTest method doesn’t do anything yet except for a fail (the Assert.Fail(…) call forces an exception to be thrown, which is how a test should fail).  My task is to write code that uses my Stacks class to create a new record in the Stacks table.  My unit test code in the CreateStackTest method should create the record, then validate that it’s there and that it’s as expected.  If it’s not 100% perfect with the result, I should throw an exception and provide message text in the exception explaining what’s wrong.  If a [Test] unit test method ends without an exception, it’s considered a success.  You should code your unit tests as such.

Running your first test session:

Compile your test suite class.

Crank up the NUnit GUI (nunit.exe).  Open the “File” menu, choose “Open Project” and browse to the folder that contains your newly compiled test and open it.

You’ll see the NUnit GUI populate a tree view on the left pane, showing all of your test methods.  If you have multiple test classes in your DLL, each class has it’s own branch and that class’s methods are child nodes under it.

Click the “Run” button and the GUI will run each of your tests, one at a time.  If the test completes with no exceptions thrown, a green dot will be displayed next to the unit test.  If it fails with an exception, a red dot is displayed.  If you’ve told it to ignore the test (with the [Ignore] attribute on the test), it will show as yellow.

On the right pane, it’ll display the errors and console output, and skipped methods.

Your goal, of course, is to have all tests complete with green dots (full success).  Any tests that fail should be carefully checked to ensure the test code was accurate, and if so, you should examine the library you’re testing to find the problem and fix it, then rerun the test.  Keep repeating this process until all tests pass.

Here’s a snapshot of my test suite against my DAL for my database:

image

It shows all the tests failed.  As it turns out, my database server is not running and all of these tests are trying to query my database.  As you can see, the tree view on the left shows each of my tests failed.  The right window panes list each error that was thrown.  The red bar means the final result of all tests was a failure (It’s only green if all tests pass).

Be sure to check back soon for my next article on tips for using NUnit and writing your own unit tests.

Leave a Reply