StructureMap 1.0 released – Don’t create a loosely coupled system without it – level 200

StructureMap is very easy to use, but it makes creating loosely coupled OO systems a breeze (ok, that’s exaggerating.  it still requires engineering).  I use it in every project I work on, and I like it better than Spring.Net.  Spring needs Xml configuration for every mapping between an interface and a class.  This causes the Xml file to continue to grow and grow and grow.  StructureMap uses Attributes to tag the interface and class definition.  At runtime, it hooks them up.  This type of metadata is much easier to manage.

Jeremy Miller recently released version 1.0 of StructureMap.  I was please he included a feature I explicitly asked for.  If you need a port to .Net 2.0, let me know.  I’ve done it.

Unit testing demonstrated – level 300

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.

Automated testing with .Net – an overview – level 200

Reality

In reality, developers don’t like to do much testing.  Developers aren’t testers.  We typically will write code while making
certain assumptions about variables and, objectively knowing the expected behavior
of the syntax, we might run it once and call it done.  Typically, bugs hide where the code wasn’t
rigorously tests or in paths that weren’t tested at all.  I think everyone agrees that without testing,
the software will have bugs (and often even after testing).  I heard of a crazy management quote that is
very sad: “If you have to test it, you aren’t building it right.”  I sure am glad that manager wasn’t involved
with automobile development!  In reality,
we need testing

 

Types of common
developer testing

  • Actually
    running the code written
  • Simple
    console application or winforms test harnesses
  • Running
    the application through the UI locally or on a development server.

 

Types of testing

  • Unit
    testing
  • Integration
    testing
  • Acceptance
    testing
  • Load
    testing
  • Performance
    testing
  • Security
    testing
  • Exploratory
    testing
  • And
    many more

 

Approaches

  • Do all
    manual testing with or without the help of small tools.
    • With
      this approach, the cost is high because for every run of the test, human
      time is required.  For every
      release, every test case must be repeated.
    • This
      approach doesn’t scale.  When more
      testing is needed, that directly calls for more human time.  Human time is very expensive compared
      to computing time.
  • Automate
    all testing.
    • The
      cost is low for about 80%, but then goes up.
    • Some
      types of tests are hard or impossible to automate effectively, such as
      security, exploratory, and concurrency testing.  This type of testing needs more human
      attention and isn’t easily repeatable.
    • To
      fully succeed at this approach, testers need to be highly skilled at
      scripting.
  • A
    pragmatic approach – automate the testing that is easiest.
    • Unit
      testing
    • Integration
      testing
    • Acceptance
      testing

Unit testing

What is a unit test? 
From Wikipedia:  A “. . . unit
test
is a procedure used to validate that a particular module of source
code is working properly”.  A unit test
is a very unique type of test with some fundamental constraints.  If a test violates a constraint, it ceases
existence as a unit test.

 

Characteristics of a
unit test

  • A unit
    test isolates and tests a single responsibility.
  • A unit
    test isolates a failure.
  • A unit
    test simulates other collaborators using various methods such as fake
    objects.
  • A unit
    test can run and pass in any environment.

When an automated test reaches out to a file, registry key,
database, web service, external configuration, environment variable, etc, it
becomes an integration test and is polluted with dependency on its
environment.  At that point, the binary
can no longer be sent to another location with the expectation that test
continue to pass. 

 

Unit testing is hard. 
It requires constant vigilance to ensure application code is
loosely-coupled.  Because a unit test
must test a piece of code in isolation, the code must be designed so that
collaborators can be easily separated. 
In short, calling out to a static method from inside a constructor is a
tight-coupling.  This type of code will
hinder unit testing.

 

Integration testing

What is integration testing? 
An integration test is a developer test that combines several units of
code and tests the interaction among them. 
A good integration strategy will include tests along all integration
boundaries.  If a unit of code is tested
at the unit level and then tested during interaction with all collaborators,
the developer has confidence that the code will work well when the entire
system is assembled.  Integration
testing
is the second step in a “test small, test medium, test large”
strategy.  Larger integration tests are certainly useful, but
large tests alone don’t help to pinpoint a problem if they fail. 

 

Characteristics of a
good integration test

  • It
    only includes a few classes.  It
    typically focuses on a single class and then includes collaborators.  If a class has 3 collaborators, the test
    would include 4 classes (the first class and its 3 collaborators).  This test would aim to fake the
    collaborators twice removed so that the focus on the test can remain
    narrow.  This is a subjective rule,
    and the developer should use good judgment regarding how many classes to
    include in an integration test.
  • It is
    completely isolated in setup and teardown. 
    Should not be environmentally sensitive.  If the test requires a file to be on the
    drive, then setup for the test should place the required file there
    first.  If the test needs data in a
    database, the setup should insert the required records first.  It should not depend on any environment
    setting being present before the test is run.  It should run on any developer
    workstation.
  • Must
    run fast.  If it’s slow, the build
    time will suffer, and you will run fewer builds.
  • It
    must be order-independent.  If an
    integration test causes a subsequent test to fail, it is indicative of a
    test not owning its own environmental setup.

 

Acceptance testing

What is acceptance testing? 
An evaluation of acceptance criteria on the system to ensure the system
meets the customers’ needs.  Before a
piece of software can be written the software team must have acceptance
criteria.  This is often called
requirements.  Acceptance testing seeks
to execute the requirements on the system for a pass/fail result.

 

Characteristics of a
good acceptance test

  • Easily
    understood by non-developers as well as the customer.
  • Easily
    created by non-developers as well as the customer.
  • When
    it passes, the customer is assured that the system behaves as needed.
  • Very
    expressive using jargon of the business domain.
  • Is
    repeatable.

 

Automated acceptance testing is the final big gain in the
suite of automated tests.  The acceptance
tests actually define requirements in an objective and executable way.  If a tester finds a bug, he can write an
acceptance test that fails in the presence of the bug.  When the bug is fixed, the test will
pass.  Acceptance tests become an
important part of a regression test suite over time.

 

Stay tuned for more
detailed information on the following testing topics:

  • Unit
    testing
  • Integration
    testing
  • Acceptance
    testing