I use NUnit for my automated tests.  Because of that, all my tests are unit tests, right?

WRONG!  The name of the testing framework has no bearing on the type of test you have.  NUnit is a framework for running automated tests.  You _can_ write unit tests with it, but you can also write integration tests as well as full-system tests with it.  A unit test is a special type of developer test and can be done with or without NUnit. 

A unit test tests a single line of code.

How big is a unit?  Well, that’s up to you, and there is not scientific answer.  Typically, you only give a class a single responsibility.  The class may have several methods since the class may need to do several things to accomplish the single responsibility.  The class may have to collaborate with several other classes to accomplish its purpose.  A unit of code is an identifiable chunk of code needed to accomplish part of a responsibility.  Is that vague enough for you?  In my example below, I’ll clear this up a bit.

A unit test isolates the code being tested.

A class will need to talk to other classes.  That’s a given.  Sometimes this is ok for testing, and sometimes this just gets in the way.  It might be ok to talk to a class that just builds a string (like StringBuilder), but it’s not ok to talk to a class that grabs information from a configuration file.  In a unit test, you need to take environmental dependencies out of the equation so that a pass or failure is truly dependent on the code being tested.  You don’t want the test failing because the configuration file wasn’t in the right spot.  There are plenty of techniques available for this.  To start, you need to code against interfaces and use fake objects like stubs and mocks.  I like the Rhino mock framework for this.

Here are some dependencies that will need to be frequently simulated for unit testing:

• Config files
• Registry values
• Databases
• Environment variables
• Machine name
• System clock (Yup.  Even that has the potential to get in your way).

Example:

This example will show a real web user control that I’ve unit-tested.  This is not theoretical.  This is inside my EZWeb software.  The purpose of the following screen is to maintain a few pieces of information for the page being viewed.  The user can set the title of the page and some other things.

I’ve used the Mode-View-Presenter pattern to make unit testing this easier.  Obviously if all my code is in the code-behind of the ASCX, then I won’t be able to test any of it because I can’t run that code outside of the ASP.NET runtime.  If you aren’t familiar with the MVP pattern now, take some time to read up on it.  The presenter is the controlling class that will be tested.  The code-behind becomes very dumb.  The code-behind will implement my view interface and be responsible for taking information and setting the correct control.  The view is very small, and all the intelligence is in the controlling class (the Presenter).  The presenter is where the bugs will hide, so I’ll unit test that class.  The model is represented by an interface IPageConfig that you’ll see being referenced.

The following example shows a unit test of the code that gets data from the model and publishes it to the view.  The textboxes and drop-downs need to be set properly.  This is not the full code.  The full code also reacts to the save button being clicked and taking modifying information and saving it.

Here is the view interface:

namespace Palermo.EZWeb.UI

{

    public interface IPagePropertiesView

    {

        string Title { get; set; }

        bool HasParent { get; set; }

        string Template { get; set; }

        string Theme { get; set; }

        string Plugin { get; set; }

        string Parameter { get; set; }

        bool IsPostback { get; }

        DictionaryList GetTemplateChoices();

        void SetTemplatesDropDown(DictionaryList list);

        DictionaryList GetThemeChoices();

        void SetThemesDropDown(DictionaryList list);

        DictionaryList GetPluginChoices();

        void SetPluginDropDown(DictionaryList list);

        void EnableTitle(bool enabled);

        void EnableTemplate(bool enabled);

        void EnableTheme(bool enabled);

        void EnablePlugin(bool enabled);

        void EnableParameter(bool enabled);

        void ReloadParent();

    }

}

Here is the code-behind that implements the view interface (truncated):

      public partial class PageAdministration : UserControl, IPlugin, IPagePropertiesView

      {

        private PagePropertiesPresenter _presenter;

        public string Title

        {

            get { return txtTitle.Text; }

            set { txtTitle.Text = value; }

        }

        public bool HasParent

        {

            get { return Convert.ToBoolean(ddlHasParent.SelectedValue); }

            set { ddlHasParent.SelectedValue = value.ToString(); }

        }

        public string Template

        {

            get { return ddlTemplate.SelectedValue; }

            set { ddlTemplate.SelectedValue = value; }

}

. . .

Here is the part of the Presenter that we’ll be focusing on:

    public class PagePropertiesPresenter

    {

        private readonly IPagePropertiesView _view;

        private ICurrentContext _context;

        public PagePropertiesPresenter(IPagePropertiesView view)

        {

            _view = view;

            _context = (ICurrentContext) ObjectFactory.GetInstance(typeof (ICurrentContext));

        }

        //testing constructor

        public PagePropertiesPresenter(IPagePropertiesView view, ICurrentContext context)

        {

            _view = view;

            _context = context;

        }

        public virtual void LoadConfiguration()

        {

            if (!_view.IsPostback)

            {

                IPageConfig config = _context.GetPageConfig();

                _view.Title = config.Title;

                _view.HasParent = config.HasParent;

                DictionaryList templates = removeBadItems(_view.GetTemplateChoices());

                _view.SetTemplatesDropDown(templates);

                _view.Template = config.Template;

                DictionaryList themes = removeBadItems(_view.GetThemeChoices());

                _view.SetThemesDropDown(themes);

                _view.Theme = config.Theme;

                DictionaryList plugins = removeBadItems(_view.GetPluginChoices());

                _view.SetPluginDropDown(plugins);

                _view.Plugin = config.Plugin;

                _view.Parameter = config.Parameter;

            }

}

.  .  .

Notice that the LoadConfiguration() method checks for postback (through the view) and then uses the MODEL to set pieces of information on the VIEW.  You may think that this code is boring, but it’s essential for the behavior of the screen.

Now for the test.  Note that we’re simulating the view and the ICurrentContext interface since these are collaborators.  The ICurrentContext provides the MODEL to the Presenter:

    [TestFixture]

    public class PagePropertiesPresenterTester

    {

        [Test]

        public void ShouldSetAllInformationOnPage()

        {

            MockRepository mocks = new MockRepository();

            IPageConfig mockConfig = (IPageConfig)mocks.CreateMock(typeof(IPageConfig));

            IPagePropertiesView view = (IPagePropertiesView)mocks.CreateMock(typeof(IPagePropertiesView));

            ICurrentContext context = (ICurrentContext)mocks.CreateMock(typeof(ICurrentContext));

            Expect.Call(view.IsPostback).Return(false);

            Expect.Call(context.GetPageConfig()).Return(mockConfig);

            string title = "fake title";

            Expect.Call(mockConfig.Title).Return(title);

            view.Title = title;

            bool hasParent = false;

            Expect.Call(mockConfig.HasParent).Return(hasParent);

            view.HasParent = hasParent;

            string selectedItem = "foo";

            Expect.Call(mockConfig.Template).Return(selectedItem);

            DictionaryList list = new DictionaryList();

            list.Add("first", "first");

            list.Add("Foo", selectedItem);

            list.Add(".svn", ".svn");

            list.Add("_something", "_something");

            Expect.Call(view.GetTemplateChoices()).Return(list);

            view.SetTemplatesDropDown(null);

            LastCall.On(view).Constraints(new PropertyIs("Count", 2));//. and _ should be stripped out.

            view.Template = selectedItem;

            Expect.Call(mockConfig.Theme).Return(selectedItem);

            Expect.Call(view.GetThemeChoices()).Return(list);

            view.SetThemesDropDown(null);

            LastCall.On(view).Constraints(new PropertyIs("Count", 2));

            view.Theme = selectedItem;

            Expect.Call(mockConfig.Plugin).Return(selectedItem);

            Expect.Call(view.GetPluginChoices()).Return(list);

            view.SetPluginDropDown(null);

            LastCall.On(view).Constraints(new PropertyIs("Count", 2));

            view.Plugin = selectedItem;

            string fakeParameter = "faky";

            Expect.Call(mockConfig.Parameter).Return(fakeParameter);

            view.Parameter = fakeParameter;

            mocks.ReplayAll();

            PagePropertiesPresenter presenter = new PagePropertiesPresenter(view, context);

            presenter.LoadConfiguration();

            mocks.VerifyAll();

}

. . .

Your first thought might be that this unit test method is too long.  It certainly pushes my comfort level as well.  I could have chosen a small one for this example, but I chose my largest one instead.  I’ve seen other unit testing examples that are so trivial that they don’t demonstrate much.  In this sample, I chose one of the most difficult things to unit test:  A UI screen.  Notice that I’m using Rhino mocks to set up my fake objects.  The call to “mocks.VerifyAll()” does a check to ensure that the collaborators were called with the correct input.  After all, my presenter method is in charge of getting information from the MODEL and publishing them to the VIEW.  If you spend some time going over this test, you can see some of the rules the code has to live by.  One of the side-effects of the unit test is documentation of the code (developer documentation).  At this point, I can refactor my method knowing that I have this test as a safety net.

How do I unit test my legacy code?

Change it.  This screen started out several years ago with all the code in the code-behind class.  It was impossible to test this way.  I had to refactor to the MVP pattern to enable testing.  I had to break some things away by inserting an interface so that I’d have a seam to break dependencies.  In short, you must refactor your existing code to get it to a point where it is testable.  The reason it’s not testable is that it’s tightly-coupled with its dependencies.  I hope by now that the words “loosely-coupled” are recognized as “good” and “tightly-coupled” are recognized as “bad”.  Testable code is loosely-coupled.  Loosely-coupled code is testable.  And now the big leap:  Testable code == good.