Figure A.5 Not enough time to test reduces the available time
Test-Driven Development: By Example by Kent Beck

It didn’t start out that way. In fact the first few lines of code I wrote were tests. The problem was I could only get about an hour or two in each night and every day that passed we were leaving money on the table.

Since I didn’t have much time at night, I didn’t want to spend it writing tests. I just wanted to get the app done. All I needed to do was sync business listings from an affiliate with GarageCommerce.com, the project I’ve been working on for the last few months. There were only a handful of business rules to deal with and I thought I could just bang it out.

I know what you’re thinking. You already know where this is headed and you might as well just skip to the end. It’s like in that movie District 9. It started out pretty good with some edgy social commentary but by the end of the movie it just phoned in a cliché Hollywood plot. You know, like “fish out of water”, “buddy movie”, or “trading places” as was the case with District 9.

Anyway, I finished the app and since I only had a few tests I figured I should trace through things a few times to look for obvious problems. After doing that for a few minutes I was ready to press F5 and start working the kinks out. So after hours of zero feedback coding, I took a deep breath and the started the app for the first time.

It promptly bombed out as expected. I worked through a handful of errors and then it was good to go. As I watched it run, I thought to myself that maybe Uncle Bob is wrong about testing and Spolsky isn’t such a douche bag after all. However after processing a couple hundred jobs, it started throwing crazy errors in a tight loop. Crap!

Fast forward a few hours and I’ve got a hunch as to what is causing the problem. The way I wired up the app, I was creating a single NHibernate session for the entire batch of jobs. I knew this could be trouble so I at least made a point to commit after each job and clear the session so it wouldn’t get bogged down with 10K+ entities. I knew the single session was smelly and the errors I was seeing prompted me to refactor.

This is where it got ugly. I needed to do a pretty major overhaul and I was mostly test-less. My blood pressure went way up with each change and the fact that I didn’t have tests just made me take larger steps with no safety net. I felt like a M.A.S.H. surgeon with guts all over the operating table. Part of me thought I should take a few steps back and regroup, but another part of me was reminded of this quote:

If you’re going through hell, keep going. – Winston Churchill

So I stuck with it and got ‘er done, but it wasn’t much fun. What did I take from this experience? No revelations really, just some common sense reinforcement. It’s like rediscovering that diet and exercise is the key to losing weight, except that I rediscovered that not having tests really sucks when you have to make changes.

To streamline this process, I thought it would be handy to use a container extension to auto generate mocks for any required interface that wasn’t explicitly registered. The best way I can explain this is with code, so here it is:

[SetUp]

public void SetUp()

{

    container = new UnityContainer()

        .AddNewExtension<AutoMockingContainerExtension>();

}

[Test]

public void Should_be_really_easy_to_test()

{

    container

        .RegisterMock<IDependencyThatNeedsExplicitMocking>()

        .Setup(d => d.MyMethod(It.IsAny<int>()))

        .Returns("I want to specify the return value");

    var service = container.Resolve<ServiceWithThreeDependencies>();

    var result = service.DoSomething();

    Assert.That(result, Is.EqualTo("I didn't have to mock the other 2 dependencies!"));

}

It really reduces the noise level in tests and lets you focus on the interesting parts of your application. Here’s the code for the container extension:

public class AutoMockingContainerExtension : UnityContainerExtension

{

    protected override void Initialize()

    {

        var strategy = new AutoMockingBuilderStrategy(Container);

        Context.Strategies.Add(strategy, UnityBuildStage.PreCreation);

    }

    class AutoMockingBuilderStrategy : BuilderStrategy

    {

        private readonly IUnityContainer container;

        public AutoMockingBuilderStrategy(IUnityContainer container)

        {

            this.container = container;

        }

        public override void PreBuildUp(IBuilderContext context)

        {

            var key = context.OriginalBuildKey;

            if (key.Type.IsInterface && !container.IsRegistered(key.Type))

            {

                context.Existing = CreateDynamicMock(key.Type);

            }

        }

        private static object CreateDynamicMock(Type type)

        {

            var genericMockType = typeof(Mock<>).MakeGenericType(type);

            var mock = (Mock)Activator.CreateInstance(genericMockType);

            return mock.Object;

        }

    }

}

In case you’re wondering about container.RegisterMock<>, it’s just extension method that you can read about here.

I made a few tweaks to a captcha library I found here and basically wrapped their CaptchaImage object in a service interface to use in my application. Pretty easy stuff, but I didn’t get it right the first time.

What’s wrong with this class? (hint: it’s highlighted in yellow)

public class HttpContextCacheCaptchaProvider : ICaptchaProvider
{
    private const string httpContextCacheKey = "4D795A45-8015-475C-A6C4-765B09EB9955";
    private ICaptchaImageFactory factory;
    private HttpContextBase context;

    public HttpContextCacheCaptchaProvider(ICaptchaImageFactory factory, HttpContextBase context)
    {
        this.factory = factory;
        this.context = context;
    }

    public void Render(Stream stream)
    {
        CaptchaImage captchaImage = factory.Create();

        context.Cache[httpContextCacheKey] = captchaImage.Text;

        using (Bitmap bitmap = captchaImage.RenderImage())
        {
            bitmap.Save(stream, ImageFormat.Jpeg);
        }
    }

    public bool Verify(string text)
    {
        string captchaText = (string)context.Cache[httpContextCacheKey];

        if (text == null || captchaText == null)
            return false;
        else
            return text.ToLower().Equals(captchaText.ToLower());
    }
}

Perhaps your nose can lead you in the right direction. The smell is hard to test, and it’s hard to test because it requires mocking the HttpContextBase. You might say “no problem, I can blast out a stub with Moq in no time” but you’re missing the real problem. That would be like taking aspirin for a brain tumor.

It’s not a tumor

The real problem is this class is violating the Single Responsibility Principle (SRP) by doing more than one thing. I don’t mean the two methods Render() and Verify(), those are a cohesive unit operating on the same data. The other thing is lifetime management. Look how simple the class gets when you invert control and take out the notion of lifetime management:

[Serializable]
public class LifetimeManagedCaptchaProvider : ICaptchaProvider
{
    private ICaptchaImageFactory factory;
    private string captchaText;

    public LifetimeManagedCaptchaProvider(ICaptchaImageFactory factory)
    {
        this.factory = factory;
    }

    public void Render(Stream stream)
    {
        CaptchaImage captchaImage = factory.Create();

        captchaText = captchaImage.Text;

        using (Bitmap bitmap = captchaImage.RenderImage())
        {
            bitmap.Save(stream, ImageFormat.Jpeg);
        }
    }

    public bool Verify(string text)
    {
        if (text == null || captchaText == null)
            return false;
        else
            return text.ToLower().Equals(captchaText.ToLower());
    }
}

Now this class is a breeze to test and all you have to do is register it like this:

Container.RegisterType<ICaptchaProvider, LifetimeManagedCaptchaProvider>(
    new HttpSessionStateLifetimeManager());

The moral of the story is let your IoC container do things it’s good at.

I must warn you, this post is about unit testing software, not donuts. With that said, I’ve been pondering the dilemma of how much time to spend writing unit tests and today I had a moment of clarity that I couldn’t help but share.

I was pairing with a coworker on Friday and we were both feeling a bit unproductive because we had spent so much time writing unit tests for a relatively small bit of code. In fact we spent more time writing tests than we spent writing the code to make the tests pass. To make matters worse, we spent more time refactoring the unit tests than we did refactoring the code that made the tests pass. We were pining over the readability of the tests as if the test were more important than the code and that left me with an uneasy feeling over the weekend.

Today I found a bit of inner peace as I embraced the the notion that the tests are more important than the code that makes them pass. Think about that for a moment. The challenge in writing software is not the implementation. Syntax, structures and algorithms are the easy parts. The real hard earned knowledge won through experience comes in the form of specifications; Understanding the intricate complexities and desired behavior of your software in the wild.

Writing software can be like swimming in the ocean when a thick fog rolls in. The mechanics of swimming are learned easily, but the real challenge is knowing which direction to swim so that you get back to the shore before you run out of energy. After a day of programming, the real asset is not the implementation of your feature, it’ s the increased understanding of your problem domain. This understanding is captured in the form of executable requirements.

When there is a bug in your system, chances are it’s a bug in your understanding of how your system should behave under a particular set of conditions. Burying an innocuous if statement in the middle of some method deep in the stack is a horrible way to reap the reward of day spent spelunking through code. It’s like eating a donut on the way home from the gym.

The legacy you leave is the the unit test, it tells the story of the hard fought knowledge and the readability of your test is more important than the readability of your implementation. Tell the next developer what’s important through an executable specification that reads like one.

The only hard part is convincing your boss that it’s not a colossal waste of time, right? Well that’s the first hurdle and yes it’s a doosie, but it’s just the price of admission. The real fun starts when you sit next to your partner and try to prove your boss wrong. After a year or so in the trenches, I’ve learned a thing or two on how to mess it up.

5. Researching new technology

“Click on that link, no wait scroll up, over there, wait I wasn’t done reading that…” That’s not pair programming, that’s insanity. Recently we were working on a project that involved a custom Firefox browser skin. Neither of us had experience with browser skins, so there was a lot of Googling and tutorial reading. As soon as we caught ourselves reading blogs and whatnot, we would split up for 15 minutes and then compare notes.

4. Getting your environment going

“Hey buddy, are you ready to start pairing on that project? Let’s see, now where is the source code for the project we’re working on… Hmm, this doesn’t compile – I think I need to install the latest version of that library.” Kill me now.

3. Paralysis

One of my favorite authors, Kurt Vonnegut would write clever things like “The man looked… guilty isn’t the right word, but it’s the first one that comes to mind.”

With pair programming, you can’t just sit there because you don’t know where to start or you can’t think of the right variable name. Just type something. You have to get the problem solving out of your head and into a medium that two people can have a conversation about it. Maybe people are afraid to type something in front of a peer if it’s not perfect. Borrow a technique from Kurt Vonnegut and as you are type, just say “I don’t want the code to look like this…” and write some awful switch case statement.

Once there is something on the screen, you and your partner are instantly aligned and solving the same problem. Now you can discuss factories and polymorphism and all kinds of heady solutions.

2. Not doing TDD

Have you ever watched an artist paint a picture and thought to yourself “what the heck is that”. Then with the next brush stroke you realize you’re looking at the profile of someone’s face. Well watching someone write code can be horribly worse than that.

Pair programming is a conversation, not a seminar or window into someone’s brain. The best way to keep things at a conversational level is to work top down which is exactly what TDD forces you to do. You must consider your code from the client perspective and challenge yourself to keep your code on purpose.

Even more importantly, TDD gives you and your buddy an “out” at regular intervals. You write a test, you make a test pass. Either way, you have many small victories over the course of a few hours and you can switch pairs at well defined feel-good stopping points.

1. Not using a timer

I used to work with a guy that was always competing with something. A mutual friend at the office was doing the 3-day breast cancer walk. If anyone in the office donated money, he would up his donation $1 higher. On the softball team, his jersey number was #1. When we started playing ping-pong at lunch, he bought a $600 ping-pong robot to practice with at home. So when he started using a timer while programming I just figured it was good old Paul racing against time.

Then I paired with him on a project. Right after wanting to strangle him for not having his environment ready, we set his timer for 30 minutes and got going. When the timer went off, we stopped mid keystroke and switched seats. This did a few things. First, it kept Paul engaged the whole time because he knew he would be in the hot seat in a few minutes, and I can be a bit of a bully so it was easier for me to back off knowing I’d get my chance soon enough. One of the more surprising benefits, however, was simply the fact that we would sit for a minute and agree exactly what we were doing before starting the timer which really got us in gear and drastically cut down on tangents.

Using a timer creates a magical dynamic that I cannot do justice with words. It’s like TDD, it’s not about the tests – it’s about the code you write to make it testable. You have to try it. Period.

“If you can do a half-assed job of anything, you’re a one-eyed man in a kingdom of the blind.” – Kurt Vonnegut