#net

In Part1 of this series I have showed you how to create a very simple mock object by hand. In this post I will show you how to use RhinoMocks to create the mock and how to verify this. This post is intended as basic advice, and won’t cover any advanced RhinoMocks topics, just the basic setup/replay/verify steps.

When working with almost any mock framework there are 3 things: Setup, expectation recording and verifying that the expectations where met.
That means, first you tell the mock object what calls to expect. Then you let the method under test do it’s magic and afterwards you let the mock verify that all expected calls where made.
You can get very precise on what to expect and how to expect it, but that will be covered in the next part of this series.

The hand-made mock from Part1 would translate to a test like this when using RhinoMocks:

[Test]
public void ServiceWatcherNotifiesUser()
{
    var repository = new MockRepository();
    var notifier = repository.StrictMock<IErrorNotifier>();


    notifier.NotifyOfServiceDown();

    repository.ReplayAll();

    var watcher = new HttpServiceWatcher(notifier);
    watcher.ObserveService();

    repository.VerifyAll();
}

The main things here:
We start the repository and then request a IErrorNotifier object from it.

var repository = new MockRepository();
var notifier = repository.StrictMock<IErrorNotifier>();

The mock object (notifier) is in record mode now, all calls we do to the object aren’t actually executed but will be expected afterwards.
So if we want NotifyOfServiceDown to be called once we simply call it while in record mode:

notifier.NotifyOfServiceDown();

After having set up all expectations in record mode, we tell the Mockrepository to go to replay mode:

repository.ReplayAll();

The mock object still doesn’t do anything. But it expects what we setup in replay. If the watcher calls methods that weren’t specified in replay mode the mock will throw exceptions at us.

Now we construct the object under test:

var watcher = new HttpServiceWatcher(notifier);

And note that we pass the mock object instead of an actual implementation of IErrorNotifier.
Now we call the method under test just as we would normally:

watcher.ObserveService();

That leaves us with only one step left, we tell the repository to verify all mocks that where created and it will throw Exceptions if mocks didn’t get called or did get called too often.

repository.VerifyAll();

Although this is just a very basic example of how to use RhinoMocks, you are able to see the benefits from this. You could write the HttpServiceWatcher class without having to write any concrete IErrorNotifier implementations. You can just concentrate on the HttpServiceWatcher instead of worrying how the underlying Service is going to work.

In the next part I’ll be covering how to make some fancier things with RhinoMocks like returning values and verifying that passed parameters meet certain criteria.

The source code is available through my SVN repository:

svn checkout https://office.pixelpoint.at:8443/svn/tigraine/UnitTesting/trunk UnitTesting –username guest

Notice that all dependencies are also in the svn, so you don’t need to get RhinoMocks or nUnit yourself.

I regret not having blogged on TDD and designing for test before – it makes it very difficult to talk about mocking as it is a rather advanced topic, requiring at least some knowledge of polymorphism and oo-design.
So this post is the first in a series of posts on the topic of testing with mock objects, that will hopefully help you with your testing.

Testing is one of the most important things in software development.
We’re all human, and we all make mistakes. And even if we discover these mistakes during development and testing, it’s almost certain that we’ll have to come back at a later point to change something, possibly breaking what already worked.
Doing a full QA cycle during initial development may look reasonable to most of us, but doing it every time you change a tiny bit in the application will certainly get you some angry mails from management.
Having good unit tests gives you a safety net for future development. By simply running the tests you can verify that things that already worked still work properly. And that’s what is important in software development.

The whole idea of unit testing is to test as little as possible while still verifying that the method under test behaves as specified and expected.
Keep this in mind, because it is important when testing classes that depend on services or other classes.

If let’s say you have a HttpServiceWatcher that is a service running somewhere and watching if a HttpService is up and running, you should test the HttpServiceWatcher class itself, not the associated notifier classes that the Watcher calls when it wants to notify you.
But how do you verify that the HttpServiceWatcher really worked and called the notifier as a result?

Let’s start with the Notifier interface:

public interface IErrorNotifier
{
    void NotifyOfServiceDown();
}

Let’s assume we have implemented a EmailNotifier class, if the HttpServiceWatcher looks like this we’re in testing-nightmare land:

public class HttpServiceWatcher
{
    public void ObserveService()
    {
        IErrorNotifier notifier = new EmailNotifier();
        notifier.NotifyOfServiceDown();
    }
}

The HttpServiceWatcher news up it’s notifier service, so every time we want to adjust the notifier, we’d have to change the ServiceWatcher and risk breaking something. Also, we can’t test the ServiceWatcher itself, because it will always call to an EmailNotifier that we can’t fake easily.

So, the correct move would be to use Inversion of Control (IoC) to inject the service into the watcher class:

public class HttpServiceWatcher
{
    private IErrorNotifier notifier;


    public HttpServiceWatcher(IErrorNotifier notifier)
    {
        this.notifier = notifier;
    }

    public void ObserveService()
    {
        notifier.NotifyOfServiceDown();
    }
}

Now, the HttpServiceWatcher class doesn’t directly depend on any concrete implementation of IErrorNotifier, the calling code takes care of creating the concrete classes. Changes to notifiers don’t get propagated to the HttpServiceWatcher.
Also, this makes it very easy to simply fake the notifier. We could either create a fake test class that inherits IErrorNotifier, or we could use a Mocking framework.

Manual mocking could look like this:

public class NotifierMock : IErrorNotifier
{
    public int notifyOfServiceDownCallCount = 0;


    public void NotifyOfServiceDown()
    {
        notifyOfServiceDownCallCount++;
    }
}

The test could then look like this:

[Test]
public void ServiceWatcherNotifiesUser_Custom_Mock()
{
    var notifier = new NotifierMock();


    var watcher = new HttpServiceWatcher(notifier);
    watcher.ObserveService();

    Assert.AreEqual(1, notifier.notifyOfServiceDownCallCount);
}

And that’s fine. It works, we verify that the watcher actually calls the notifier service, and all is well.
It just gets tricky when you get more tests, you’ll have to create many mock objects that always introduce the possibility of breaking other tests etc.

In the next post in this series I will try to illustrate how to do the same thing with RhinoMocks and how it makes testing very easy.

Download the source code from my SVN Repository by doing a:

svn checkout https://office.pixelpoint.at:8443/svn/tigraine/UnitTesting/trunk UnitTesting –username guest

Continue reading Unit testing with mocks – Rhino Mocks basics (Part 2)

I regret not having blogged on TDD and designing for test before – it makes it very difficult to talk about mocking as it is a rather advanced topic, requiring at least some knowledge of polymorphism and oo-design.
So this post is the first in a series of posts on the topic of testing with mock objects, that will hopefully help you with your testing.

Testing is one of the most important things in software development.
We’re all human, and we all make mistakes. And even if we discover these mistakes during development and testing, it’s almost certain that we’ll have to come back at a later point to change something, possibly breaking what already worked.
Doing a full QA cycle during initial development may look reasonable to most of us, but doing it every time you change a tiny bit in the application will certainly get you some angry mails from management.
Having good unit tests gives you a safety net for future development. By simply running the tests you can verify that things that already worked still work properly. And that’s what is important in software development.

The whole idea of unit testing is to test as little as possible while still verifying that the method under test behaves as specified and expected.
Keep this in mind, because it is important when testing classes that depend on services or other classes.

If let’s say you have a HttpServiceWatcher that is a service running somewhere and watching if a HttpService is up and running, you should test the HttpServiceWatcher class itself, not the associated notifier classes that the Watcher calls when it wants to notify you.
But how do you verify that the HttpServiceWatcher really worked and called the notifier as a result?

Let’s start with the Notifier interface:

public interface IErrorNotifier
{
    void NotifyOfServiceDown();
}

Let’s assume we have implemented a EmailNotifier class, if the HttpServiceWatcher looks like this we’re in testing-nightmare land:

public class HttpServiceWatcher
{
    public void ObserveService()
    {
        IErrorNotifier notifier = new EmailNotifier();
        notifier.NotifyOfServiceDown();
    }
}

The HttpServiceWatcher news up it’s notifier service, so every time we want to adjust the notifier, we’d have to change the ServiceWatcher and risk breaking something. Also, we can’t test the ServiceWatcher itself, because it will always call to an EmailNotifier that we can’t fake easily.

So, the correct move would be to use Inversion of Control (IoC) to inject the service into the watcher class:

public class HttpServiceWatcher
{
    private IErrorNotifier notifier;


    public HttpServiceWatcher(IErrorNotifier notifier)
    {
        this.notifier = notifier;
    }

    public void ObserveService()
    {
        notifier.NotifyOfServiceDown();
    }
}

Now, the HttpServiceWatcher class doesn’t directly depend on any concrete implementation of IErrorNotifier, the calling code takes care of creating the concrete classes. Changes to notifiers don’t get propagated to the HttpServiceWatcher.
Also, this makes it very easy to simply fake the notifier. We could either create a fake test class that inherits IErrorNotifier, or we could use a Mocking framework.

Manual mocking could look like this:

public class NotifierMock : IErrorNotifier
{
    public int notifyOfServiceDownCallCount = 0;


    public void NotifyOfServiceDown()
    {
        notifyOfServiceDownCallCount++;
    }
}

The test could then look like this:

[Test]
public void ServiceWatcherNotifiesUser_Custom_Mock()
{
    var notifier = new NotifierMock();


    var watcher = new HttpServiceWatcher(notifier);
    watcher.ObserveService();

    Assert.AreEqual(1, notifier.notifyOfServiceDownCallCount);
}

And that’s fine. It works, we verify that the watcher actually calls the notifier service, and all is well.
It just gets tricky when you get more tests, you’ll have to create many mock objects that always introduce the possibility of breaking other tests etc.

In the next post in this series I will try to illustrate how to do the same thing with RhinoMocks and how it makes testing very easy.

Download the source code from my SVN Repository by doing a:

svn checkout https://office.pixelpoint.at:8443/svn/tigraine/UnitTesting/trunk UnitTesting –username guest

Continue reading Unit testing with mocks – Rhino Mocks basics (Part 2)

Don’t repeat yourself is one of the most important principles I know of. And there are many ways to follow DRY when it comes to normal code.

But when you go to Winforms-land most people forget about DRY and create the same Gui code over and over again. Some of them are clever and abstract the “handlers” away from the buttons, but they still draw most of the buttons multiple times for forms that look almost exactly the same.

But it’s pretty common to have multiple views of the same forms. Like a CreateNewUser and a UpdateExistingUser mask, they both share almost all textboxes, but their values get processed differently.

You could try to use the same form for both operations, but that violates SRP (and makes things a lot harder), or you have two different forms that inherit the controls from a parent form.

Tha't’s then called Visual Inheritance. And, sadly the Windows Forms designer within Visual Studio is pretty bad at it, it crashed on my multiple times.

After 2 hours of fooling around with the Designer to get my Forms to show again I decided to share my experience, since there are some simple rules that you can follow to not break your design surface:

Don’t remove the default constructor from your parent form

The designer depends on a parameterless constructor, if you want to have parameters create a new constructor (and therefore don’t forget to call InitializeComponent again)

Don’t hook up Form_Load events in your parent form

I sincerely have no clue why this breaks the designer, but it does.

It’s rather tragic that the designer breaks on working code (compiling and running my code always worked, the designer just couldn’t load the form to show the design surface), but if you follow the above guidelines everything should work out fine.

There is also another way to remove code duplication by using Custom Controls and User Controls, these get handled better by the designer, but require a bit more thinking when creating (You may get in trouble when you try to modify their instantiation because that’s done during the InitializeComponent call).

Don’t repeat yourself is one of the most important principles I know of. And there are many ways to follow DRY when it comes to normal code.

But when you go to Winforms-land most people forget about DRY and create the same Gui code over and over again. Some of them are clever and abstract the “handlers” away from the buttons, but they still draw most of the buttons multiple times for forms that look almost exactly the same.

But it’s pretty common to have multiple views of the same forms. Like a CreateNewUser and a UpdateExistingUser mask, they both share almost all textboxes, but their values get processed differently.

You could try to use the same form for both operations, but that violates SRP (and makes things a lot harder), or you have two different forms that inherit the controls from a parent form.

Tha't’s then called Visual Inheritance. And, sadly the Windows Forms designer within Visual Studio is pretty bad at it, it crashed on my multiple times.

After 2 hours of fooling around with the Designer to get my Forms to show again I decided to share my experience, since there are some simple rules that you can follow to not break your design surface:

Don’t remove the default constructor from your parent form

The designer depends on a parameterless constructor, if you want to have parameters create a new constructor (and therefore don’t forget to call InitializeComponent again)

Don’t hook up Form_Load events in your parent form

I sincerely have no clue why this breaks the designer, but it does.

It’s rather tragic that the designer breaks on working code (compiling and running my code always worked, the designer just couldn’t load the form to show the design surface), but if you follow the above guidelines everything should work out fine.

There is also another way to remove code duplication by using Custom Controls and User Controls, these get handled better by the designer, but require a bit more thinking when creating (You may get in trouble when you try to modify their instantiation because that’s done during the InitializeComponent call).

I’ve been doing some Windows Forms development lately and really love it. After doing web development for the last couple of years I am thankful for the change. Being able to create compelling UIs without having to worry about Javascript is something I’ve been longing for quite some time.

But when trying to build intuitive and user-friendly UIs, you hit the boundaries of Microsoft’s control toolbox pretty fast. (Not as fast as with Webcontrols, but still).
I needed a Textbox that accepts only decimal input and that formats itself rather nicely for a finance application I’m building right now.

I first turned to the MaskedTextBox control that’s already there, but that turned out to be completely useless because numbers have no fixed length.
So I decided to create a Custom Control that derives from TextBox that does exactly what I need – take decimals and nothing else.

The whole process is rather simple, so I’ll just give you the code and be done with it. The DecimalTextbox control won’t accept any input that’s not numeric except for one comma. If you leave the control empty or non-decimal (however you accomplish that) it will revert to 0,00 on validation.

The code is after the break

public partial class DecimalTextBox : TextBox
{
    public DecimalTextBox()
    {
        InitializeComponent();
    }


    protected override void OnTextChanged(EventArgs e)
    {
        if (IsDecimal())
            base.OnTextChanged(e);
    }

    protected override void OnKeyPress(KeyPressEventArgs e)
    {
        if (!char.IsNumber(e.KeyChar)
            && ((Keys)e.KeyChar != Keys.Back)
            && (e.KeyChar != ','))
            e.Handled = true;

        if (e.KeyChar == ',' && Text.IndexOf(',') > 0)
            e.Handled = true;

        base.OnKeyPress(e);
    }

    protected override void OnGotFocus(EventArgs e)
    {
        ResetValueOnFocus();
        base.OnGotFocus(e);
    }

    private void ResetValueOnFocus()
    {
        if (IsDecimal())
        {
            if (!IsDecimalZero())
                return;
        }
        Text = "";
    }

    private bool IsDecimal()
    {
        decimal result;
        return decimal.TryParse(Text, out result);
    }

    private bool IsDecimalZero()
    {
        return (decimal.Parse(Text) == 0);
    }

    private void DecimalTextBox_Validating(object sender, CancelEventArgs e)
    {
        decimal value;
        decimal.TryParse(Text, out value);

        const string NUMBER_FORMAT_2_DIGITS = "N2";
        Text = value.ToString(NUMBER_FORMAT_2_DIGITS);
    }

    public decimal Value
    {
        get
        {
            return decimal.Parse(Text);
        }
    }
}

And since copying source from HTML sucks here’s the DecimalTextBox.cs.

I’ve been doing some Windows Forms development lately and really love it. After doing web development for the last couple of years I am thankful for the change. Being able to create compelling UIs without having to worry about Javascript is something I’ve been longing for quite some time.

But when trying to build intuitive and user-friendly UIs, you hit the boundaries of Microsoft’s control toolbox pretty fast. (Not as fast as with Webcontrols, but still).
I needed a Textbox that accepts only decimal input and that formats itself rather nicely for a finance application I’m building right now.

I first turned to the MaskedTextBox control that’s already there, but that turned out to be completely useless because numbers have no fixed length.
So I decided to create a Custom Control that derives from TextBox that does exactly what I need – take decimals and nothing else.

The whole process is rather simple, so I’ll just give you the code and be done with it. The DecimalTextbox control won’t accept any input that’s not numeric except for one comma. If you leave the control empty or non-decimal (however you accomplish that) it will revert to 0,00 on validation.

The code is after the break

public partial class DecimalTextBox : TextBox
{
    public DecimalTextBox()
    {
        InitializeComponent();
    }


    protected override void OnTextChanged(EventArgs e)
    {
        if (IsDecimal())
            base.OnTextChanged(e);
    }

    protected override void OnKeyPress(KeyPressEventArgs e)
    {
        if (!char.IsNumber(e.KeyChar)
            && ((Keys)e.KeyChar != Keys.Back)
            && (e.KeyChar != ','))
            e.Handled = true;

        if (e.KeyChar == ',' && Text.IndexOf(',') > 0)
            e.Handled = true;

        base.OnKeyPress(e);
    }

    protected override void OnGotFocus(EventArgs e)
    {
        ResetValueOnFocus();
        base.OnGotFocus(e);
    }

    private void ResetValueOnFocus()
    {
        if (IsDecimal())
        {
            if (!IsDecimalZero())
                return;
        }
        Text = "";
    }

    private bool IsDecimal()
    {
        decimal result;
        return decimal.TryParse(Text, out result);
    }

    private bool IsDecimalZero()
    {
        return (decimal.Parse(Text) == 0);
    }

    private void DecimalTextBox_Validating(object sender, CancelEventArgs e)
    {
        decimal value;
        decimal.TryParse(Text, out value);

        const string NUMBER_FORMAT_2_DIGITS = "N2";
        Text = value.ToString(NUMBER_FORMAT_2_DIGITS);
    }

    public decimal Value
    {
        get
        {
            return decimal.Parse(Text);
        }
    }
}

And since copying source from HTML sucks here’s the DecimalTextBox.cs.

I confess, I’ve done projects that have Console.WriteLine or Debug.Print written all over the place. Sometimes I encapsulated that stuff into a separate Log Class that got passed around to every one, or sometimes I just created this little singleton that did the logging.

Either way, it was code I didn’t really want to write until late in development where I had to go back and retrofit logging into the application. And almost every time I did this it sucked and wasn’t satisfying at all. It worked, but I could have spent countless hours on polishing the logging stuff.

That was until I found Log4Net, the .NET implementation of the open-source log4j framework.

Log4Net enables you to just forget about the logging altogether while you develop your application. Just categorize your log statements into the 5 prioritized levels (DEBUG, INFO, WARN, ERROR, FATAL) and think about the configuration some other day.

Log4Net is completely Xml configuration driven and provides a very high degree of extensibility (Just implement new Appenders, Filters or Layouts).
So it keeps decisions about the where/how/when to log absolutely open until the very end.

Hell, you can even configure a file watcher and change the Log4Net Xml configuration during runtime!

Log4Net has just made it to my imaginary “must reference in each project” list. I strongly suggest you check it out.

I confess, I’ve done projects that have Console.WriteLine or Debug.Print written all over the place. Sometimes I encapsulated that stuff into a separate Log Class that got passed around to every one, or sometimes I just created this little singleton that did the logging.

Either way, it was code I didn’t really want to write until late in development where I had to go back and retrofit logging into the application. And almost every time I did this it sucked and wasn’t satisfying at all. It worked, but I could have spent countless hours on polishing the logging stuff.

That was until I found Log4Net, the .NET implementation of the open-source log4j framework.

Log4Net enables you to just forget about the logging altogether while you develop your application. Just categorize your log statements into the 5 prioritized levels (DEBUG, INFO, WARN, ERROR, FATAL) and think about the configuration some other day.

Log4Net is completely Xml configuration driven and provides a very high degree of extensibility (Just implement new Appenders, Filters or Layouts).
So it keeps decisions about the where/how/when to log absolutely open until the very end.

Hell, you can even configure a file watcher and change the Log4Net Xml configuration during runtime!

Log4Net has just made it to my imaginary “must reference in each project” list. I strongly suggest you check it out.

Ok, since my last post where I tried out CruiseControl.NET some time has passed.

Although I said last time setting up CCNet is easy and quick, this time I didn't listen to my own advice, and so when I needed a Continuous Integration system I went TeamCity.

TeamCity is great, just click on some buttons and your CI is running.
Log in to the website, configure everything through GUI and you're done.

Sadly, I wasn't done. Something with TeamCity's build runners wasn't working right and it wouldn't resolve my NUnit dependencies and fail to build at all.
I then tried to troubleshoot TeamCity for almost a day before I finally gave up and just installed CruiseControl.NET again.

CCnet on the other hand just worked great, and I was up and running smoothly after an hour or so. And since my last post was lacking, after the break is a step-by-step guide to setting  it up.

Subversion

I assume you have Visual SVN Server up and running already (or something else), so I'll skip this step.

CruiseControl.NET

Download and install the latest CruiseControl.NET from SourceForce

During installation CCnet installs two components, the webdashboard and the CCnet server. The webdashboard will automagically be installed into a IIS virtual directory so you can access it through http://localhost/ccnet

Although you can already access the webdashboard, you will not find much to do there since the CCnet service isn't started by default and is also lacking configuration.

Configuring the CruiseControl.NET server

Now, this is when the fabulous CCnet documentation comes in to play.
In the C:\Program Files\CruiseControl.NET\server\ directory you'll find a file called ccnet.config
I won't cover all basic steps since they are already well documented, but just point out the important ones in my config.

<sourcecontrol type="svn">
  <executable>C:\Programme\VisualSVN Server\bin\svn.exe</executable>
  <trunkUrl>https://localhost:8443/svn/myProject/trunk/</trunkUrl>
  <tagBaseUrl>https://localhost:8443/svn/myProject/tags/ccnet-builds/</tagBaseUrl>
  <username>username</username>
  <password>password</password>
  <autoGetSource>true</autoGetSource>
  <tagOnSuccess>true</tagOnSuccess>
</sourcecontrol>

The <sourcecontrol> block configures CCnet to access Subversion and retrieve the source. Notably: tagOnSuccess will automatically create a new tag in the tagBaseUrl directory depending on the later labeller block.

<labeller type="defaultlabeller">
  <prefix>myProject-alpha-0.1-build-</prefix>
  <incrementOnFailure>false</incrementOnFailure>
</labeller>

This labeller block has many many options for labeling your build, but I choose to just increment my build number on every successful build with the defaultlabeller. It's a bit too early for my current project, but at a later stage I think I'll exchange that labeller with a iterationlabeller that calculates an iteration number based on weeks since release in addition to the build number.

The nunit block in the tasks section defines where my NUnit console runner is located and what assembly should be tested upon build. It's pretty straight forward, but still I think it's important.

Yeah, and that's all. XML Configurationa always looks awfully complicated, but once you look over the angle bracket porn you'll find it pretty easy to configure and modify.

One tip though: Never try to debug your configuration through the windows service. Run the ccnet.exe from the console so you get all debug output to the console. This makes fixing and tweaking your ccnet.config very easy and less "voodoo".

Because starting is easiest with a sample configuration file. Here is mine:

ccnet.config