How to write a unit test

Last week I had the pleasure of participating in Sela Developer Practice.
Before my session I sat through Gil ZIlberfeld’s session “7 steps for writing your first unit test” and I found myself thinking – what are steps I take when writing a new unit test?
I’ve been writing them for so long and never noticed I’ve been following a “methodology” of sort. And so without further ado – here is the steps I take when writing a new unit test:

The code under test

In order to write a unit test I’ll need an example and so  I came up with the following scenario:

This is the latest and greatest bug tracking software and we need to add a feature – send an email when a bug with certain severity is created.

The code we want to test looks something (read: exactly) like this:

public class BugTracker
{
    private readonly IBugRepository _repository;
    private readonly IEmailClient _emailClient;

    public BugTracker(IBugRepository repository, IEmailClient emailClient)
    {
        _repository = repository;
        _emailClient = emailClient;
    }

    public Bug CreatNewBug(string title, Severity severity)
    {
        if (string.IsNullOrEmpty(title))
        {
            throw new ApplicationException("Title cannot be empty");
        }

        var newBug = new Bug
             {
                 Title = title,
                 Severity = severity
             };

        SaveBugToDb(newBug);

        // Here be code        

        return newBug;
    }

And so since we’re avid TDD (Test Driven Design) practitioners we’ll start by writing the test first.

Decide what you’re testing

Although this might sound trivial – deciding what to test is a step that many developers tend to forget - instead they write a chunk of code and assert whatever they can.
I found that naming the test method in such a way that forces me (and my fellow developers) to think about what they are about to do:

[TestFixture]
public class BugTrackerTests
{
    [Test]
    public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
    {
        
    }
}

I didn't invent this naming convention but I find it very useful. The name is divided into three parts:

1. The method I’m testing - not description, scenario just the name of the method
2. The scenario I’m testing
3. What I expect to happen

The added benefit is that when this test would fail – all I need is to read the name of the test to know what went wrong – take that F5!
There are other similar naming schemas – choose one and be persistent about it.
So now I know what I’m about to test and the next step is to write exactly that.

Write the method under test

I’m starting from the bare minimum and building my test from the inside out.
First I’ll create the class I’m testing and then I’ll run the method I’m testing.

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var cut = new BugTracker();

    cut.CreatNewBug("my title", Severity.OhMyGod);
}

Unfortunately this does not even compile. The problem is that I need to “feed” the BugTracker class two dependencies of type IBugRepository and IEmailClient – so let’s add them courtesy of an Isolation framework (in this case FakeItEasy):

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var fakeBugRepository = A.Fake<IBugRepository>();
    var fakeEmailClient = A.Fake<IEmailClient>();

    var cut = new BugTracker(fakeBugRepository, fakeEmailClient);

    cut.CreatNewBug("my title", Severity.OhMyGod);
}

And now we can write the actual assertion.

Write the assertion

Since we need to check that our email client has sent a message we need to use the power of our isolation framework to assert exactly that

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var fakeBugRepository = A.Fake<IBugRepository>();
    var fakeEmailClient = A.Fake<IEmailClient>();

    var cut = new BugTracker(fakeBugRepository, fakeEmailClient);

    cut.CreatNewBug("my title", Severity.OhMyGod);

    A.CallTo(() => fakeEmailClient.Send("manager@project.com", "Don't Panic!")).MustHaveHappened();
}

Run the test

Now that we have all the parts placed it’s time to run the test and see it fails.
The test did fail but from the wrong reasons:


It appear I have a code inside the method “SaveBugToDb” that throws an exception:

private void SaveBugToDb(Bug newBug)
{
    if (!_repository.Connected)
    {
        throw new ApplicationException("Cannot access bug repository");
    }

    _repository.Save(newBug);
}

This means going back to the drawing board for us.

Add more code

In order to make the test fail from the correct reason I’ll add one more line courtesy of our Isolation framework to make sure that a call to Connected will always return true:

[Test]
public void CreatNewBug_CreateBugHasHighestSeverity_SendEmailToProjectManager()
{
    var fakeBugRepository = A.Fake<IBugRepository>();
    A.CallTo(() => fakeBugRepository.Connected).Returns(true);

    var fakeEmailClient = A.Fake<IEmailClient>();

    var cut = new BugTracker(fakeBugRepository, fakeEmailClient);

    cut.CreatNewBug("my title", Severity.OhMyGod);

    A.CallTo(() => fakeEmailClient.Send("manager@project.com", "Don't Panic!")).MustHaveHappened();
}

Run the test (again)

No I run the test again and it fails on the assertion. If it wasn’t the case I would go back and add more code to make sure that the test follow the correct path until I’m satisfied that I’m testing the correct thing.

Write the code to make the test pass

This one is simple – just add the code that makes the test pass:

public Bug CreatNewBug(string title, Severity severity)
{
    if (string.IsNullOrEmpty(title))
    {
        throw new ApplicationException("Title cannot be empty");
    }

    var newBug = new Bug
         {
             Title = title,
             Severity = severity
         };

    SaveBugToDb(newBug);

    if (severity == Severity.OhMyGod)
    {
        _emailClient.Send("manager@project.com", "Don't Panic!");
    }

    return newBug;
}

Conclusion

1. So what did we do:
2. Decided what to test
3. Write the method under test
4. Add assertion
5. Run the test
6. Add more code
7. Repeat steps 4,5 if necessary
8. Write the code that makes the test pass

A few comments before the end:

• This is nothing new if you’re been writing unit tests in the past – you’ve probably followed a similar process – I just needed to write is down explicitly.
• It seems like a lot of steps just to create a single test? Don’t despair - writing all of them should not take too long and besides – can you write a test without going through all of them in one way or another.
• I'm a true believer of writing the tests before the code but don’t worry this method sans step 7 will work even if you write your tests retroactively.

Happy coding…

Sela Developer Practice 2013

I’m speaking at SDP2013 – two weeks from now.

 

 

I’ll be talking about mocking (surprise!) in “Battle of the Mocking Frameworks”.

 

So if you’re happen to come to the conference on May 7th – drop by and say hi.

 

Until then – happy coding…

Unit testing multi threaded code–Timers

Writing unit tests for multi-threaded is not simple and could even be impossible for some scenarios – how could you test that an asynchronous method was not called?
Since most unit testing examples tend to be rather trivial I’ve decided to try and explain other more complex scenarios – preferably without using any calculator examples.

The “Timer” problem

Consider the Timer class (or rather classes), .NET has several classes called Timer, In this post I’m referring to System.Threading.Timer and System.Timers.Timer which is built on top of the former.
Both perform an action in another thread (using the Thread Pool) in intervals (not accurately – but I won’t go there in this post).
Consider the following class:

public class ClassUnderTest
{
    private readonly Timer _timer;

    public ClassUnderTest()
    {
        _timer = new Timer(1000);
        _timer.Elapsed += PerformPeriodicAction;
        _timer.Start();
    }

    public ClassUnderTest(Timer timer)
    {
        _timer = timer;
        _timer.Elapsed += PerformPeriodicAction;
        _timer.Start();
    }

    private void PerformPeriodicAction(object sender, ElapsedEventArgs e)
    {
        // Perform very important task here!
    }
}

Testing code that employs timers can be tricky. Unfortunately there’s a tendency to write a test that looks like this when timers are involved:

[Test]
public void TestJustWrong()
{
    var cut = new ClassUnderTest();

    // Make sure the timer executed at least once
    Thread.Sleep(5000);

    // Check that something happens
}

So what is the problem?

Although it might seem like a valid unit test – in fact it’s a test that would fail from time to time - whenever the timer would happen to “tick” for more than the sleep period.
These kind of tests are known as the “the test that tends to fail” and usually “fixed” by running the build script another time.
You do not want a test that you cannot trust to fail only when a bug is introduced into your system.
Sadly I’ve seen this code – a lot! But no more - writing a good unit test for that class is simple, in fact there is more than one alternative that creates a simple, trustworthy unit test.

Solution 1 – invoke the handler instead

Instead of waiting for the time to execute why not call the method that handles the timer’s event?
First we need to make sure that the method we’re going to call is internal or public. I personally don’t like changing my production code that much in order to make the code “testable” but it’s a way.
Now all we have to do is call the method thus making sure that execution happens exactly when we want it – and a unit test is born:

[Test]
public void TestByMethod()
{
    var cut = new ClassUnderTestForTestability();

    // Let's call the method
    cut.PerformPeriodicAction(this, null);

    // Check that something happens
}

Solution 2 – invoke the timer at your leisure

Most modern Isolation (a.k.a Mocking) frameworks have the ability to invoke events as well as create fake objects.
We’re going to create a fake timer and invoke the elapsed event. Using simple constructor injection we’ll pass the timer to our class under test prior to invocation and we have a more robust unit test:

[Test]
public void TestWithFakeTimer()
{
    var fakeTimer = Isolate.Fake.Instance<Timer>();

    var cut = new ClassUnderTest(fakeTimer);

    // Let's invoke the event
    Isolate.Invoke.Event(() => fakeTimer.Elapsed += null, this, null);

    // Check that something happens
}

I’m using Typemock Isolator but you can use the isolation framework of your choice The syntax is strange but once you’ll get used to it, it’s simple.
The added value is that we’re causing the real flow of our program to execute – in a synchronized and timely manner.

Conclusion

Although there are many ways to test code that uses timers I find myself employing the two above most of the time.
I plan to write a few more posts on the other pitfall of testing multi-threaded code (and how to avoid them) but until then –

happy coding…

Spreading the agile joy

I finally hit critical mass!

I got a request from one of the project managers (not my project) to do a quick “introduction to Scrum” session.

It took quite a while – more than two years (and a downsizing) in order for other teams to notice that we have a different way to do things.

I did a very successful session – mainly because the audience “felt the pain”; it was fun explaining about Scrum with examples on how they can utilize it the very next day.

Since I’m not in daily contact with that team – I had no idea how well they implemented Scrum. Until yesterday when I walked on a meeting that had a task board on a big screen – so I guess it went well.

When I was first asked to do this session I wanted to create a simple and short presentation that can be re-used – And here it is:

Introduction to scrum from Dror Helper

 

It’s simple and short so I use it as a “background” for a discussion on how they are going to use Scrum in their work – today.

 

I guess I’m doing something right since I have another session next week!

 

And if you have an agile success story – please share…

Things I learnt reading C# specifications (#1)

After reading Jon Skeet’s excellent C# in Depth - again (3rd edition - to be published soon) I’ve decide to try and actually read the C# language specification…
Being a sensible kind of guy I’ve decided to purchase the annotated version which only cover topics up to .NET 4 – but has priceless comments from several C# gurus.
After I’ve read a few pages I was amazed to learn that a few things I knew to be true were completely wrong and so I’ve decided to write a list of new things I’ve learnt while reading this book.
Below you’ll find a short list of new things I learnt from reading the 1st chapter:

Not all value types are saved on the stack

Many developers believe that reference types are stored on the heap while value types are always  stored on the stack – this is not entirely true.
First it’s more of an implementation detail of the actual runtime and not a language requirement but more importantly it’s not possible – consider a class (a.k.a reference type) which has a integer member (a.k.a value type),  the class is stored on the heap and so are it’s members including the value type since its data is copied “by-value”.

class MyClass
{
    // stored in heap
    int a = 5;  
}

For more information read Eric Lippert’s post on the subject – he should know.

What the hell is “protected internal”

If you’ve written more than one class you’ve probably used public/internal and protected access modifier:

class MyClass
{
    // Can only be accessed by MyClass
    private object a;

    // Accessible by MyClass and classes that derive from it
    protected object b;

    // Accessible by this assembly
    internal object c;

    // Accessible by everyone 
    public object d;
}

So what does protected internal means?

Some believe that members marked as “protected internal” are only accessible for classes that derive from MyClass AND are defined at the same assembly in fact it means that classes that derive from MyClass OR are defined on the same assembly as my class can access that member. So it’s just like using internal and protected at the same time – confused yet?

Use only immutable types as a readonly fields

How many times have you marked a field readonly?

You probably did it to make sure that a field cannot change after initialization – think again:

class Person
{
    static readonly Person Me = new Person("Dror", "Helper");
}

public void UpdateFail()
{
    // Compilation error!
    Person.Me = new Person("Kaiser", "Soze");
}

public void JustBecauseYouCan()
{
    // This would work!
    Person.Me.First = "Kaiser";
    Person.Me.Last = "Suze";
}   

That’s right, while you cannot replace the the readonly field – you can update the heck out of it.

Of course there’s more, I choose these examples because they helped me understand C# better.

I hope to add more such insights as I continue reading the book – so stay tuned…

Happy coding…

Fluent interfaces in C# – Generics

If you haven’t read the previous posts on the subject of fluent interfaces using C# – I suggest you do so now – I’ll wait…

1. Introduction
2. Extension Methods
3. Method Chaining

Great! now you’re all ready for the forth post on the subject of using Generics:

Generics were added to version 2.0 of the C# language and the common language runtime (CLR). Generics introduce to the .NET Framework the concept of type parameters, which make it possible to design classes and methods that defer the specification of one or more types until the class or method is declared and instantiated by client code.
[Generics (C# Programming Guide)]

Using generics tor return specific type

If you’ve been programming in C# you’re probably seen generics in the past– either a type safe collection (i.e. List<T>) or written your own generic class/method.
Using Generics in your API is just like saying “of type X” as part of the interface – for example “create a fake/mock of type ILogger”:

// Typemock Isolator
var fakeLogger = Isolate.Fake.Instance<ILogger>();

// Telerik's JustMock
var fakeLogger = Mock.Create<ILogger>();

// NSubstitute 
var fakeLogger = Substitute.For<ILogger>();

Reading the code above you’ll notice something - even if you are not familiar with the topic of mocking frameworks you can still understand what each line does.

The reason that this API is used in mocking frameworks is that they all have something in common – they need to create a new instance of type X -  and so they get the type parameter as part of the method call a.k.a generics.

Using Generics to configure action(s) on specific type

If you’re familiar with .NET IoC you might recognize the following API:

Kernel.Register(
   Component.For<ICustomer>()
       .Named("customer")
       .ImplementedBy<CustomerImpl>()
       .Activator<MyCustomerActivator>()
   );

In this example we use generics to configure a component and bind implementation to specific type and use another concrete type to create that instance.

Another example which I use in my project is binding message types to handling method. We have a TCP client (non WCF – what a shame) that returns messages from a single event. Each message type should be handled by a different method (logic).

Using generics and method chaining got us the following solution:

var repo = new MessageHandlerContainer();
repo.Register<ConcreteMessage1>().With(SendEmailNotification)
    .Register<AnotherMessage>().With(SoundAlarm);

// when a message arrive
var newMessage = GetNextMessage();

container.ProcessMessage(newMessage);

Easy to understand what each the code does – without reading the actual implementation.

But just in case – here you go:

public class MessageHandlerContainer
{
    private readonly Dictionary<Type, IMessageHandler> _messageHandlers =
        new Dictionary<Type, IMessageHandler>();

    public void ProcessMessage(IMessage message)
    {
        _messageHandlers[message.GetType()].Run();
    }

    public MessageHandler<T> Register<T>() where T : IMessage
    {
        var messageHandler = new MessageHandler<T>();

        _messageHandlers.Add(typeof(T), messageHandler);

        return messageHandler;
    }
}

The trick in inside the MessageHandler class which adds an action and return the parent container so that you may register yet another message:

public class MessageHandler<T> : IMessageHandler
{
    private readonly MessageHandlerContainer _parent;
    private Action<IMessage> _actionToRun;

    public MessageHandler(MessageHandlerContainer parent)
    {
        _parent = parent;
    }

    public MessageHandlerContainer WithHandler(Action<IMessage> actionToRun)
    {
        _actionToRun = actionToRun;

        return _parent;
    }

    public void Run()
    {
        _actionToRun();
    }
}

It’s not the simplest code to follow – but when you see the usage example (scroll up) you’ll notice it makes a very readable API. Now it’s very simple to add another message handler to the logic without risking spaghetti code.

Conclusion

Generics are very powerful and can be used to in your fluent API to create and register specific types.

There are other uses for generics other than these two but you’ll have to wait for a different blog post – or experiment and find out by yourself.


Happy coding…

nCrunch review – TDD on steroids

Any project that uses unit tests gets to the stage where running all of the tests takes a lot of time. Even if you manage to keep your test suite in a manageable size From time to time a developer would “forget” to run all the tests before commit and break the build.

One solution for these problems is to have an automatic test runner/continuous testing tool that runs the tests automatically.

The idea of continuous testing has it’s roots in the Java world. JUnitMax which was create by Kent Beck, runs all of the tests on each save. The order of the tests is determined by risk – the first tests run were the ones that failed on the previous run. Although this solution does not solve long run times it does make sure that your code is constantly being verified.

In the .NET space there are several such tools one of which shine above the rest -  nCrunch.

Getting started

nCrunch is code coverage, test runner and performance analyzer all in one. Using it is simple – all you need to do is to choose to enable it and after filling a few options you’re ready to go.

You can choose how many CPU cores to dedicate to running of tests and whether or not you wish to run your tests in parallel. Another option is to run the test manually – in case you “only” wish to use nCrunch as a test runner.

Running nCrunch

After this short configuration nCrunch would automatically discover all of the unit test in your solution and try to run them. So far I’ve used it with NUnit, and XUnit and it worked perfectly. On each save the code is compiled, and tests are run . nCrunch can be configured to run only the tests affected by the last code change. I’ve used this option thus avoiding a long test run with each change I make.

Another plus is the continuous code coverage results, each line of code written is immediately marked as covered/not covered by unit tests and if that unit test(s) fail – it is also marked in red.

When a test fails nCrunch provide full exception information and an arsenal of debugging options to choose from – from simple “run in debug” to “Break into the first failing covering test at this line”.

Supercharge your unit tests

nCrunch is one of these tools I’ve been looking for without actually realizing it. Using it makes TDD (Test Drive Development) easy to follow. If you want an excellent example – take a look at this video (YouTube):

Around 1:10 it really gets interesting when the code is written and the tests are executed side by side

Conclusion

nCrunch is not the only continuous testing tool out there but it’s certainly the most mature one – with easy configuration and many useful features it’s the unit testing productivity tool that I was look for.