Why Testing Reality is Always My First Test

A couple days ago I tweeted a screenshot of a unit test that is usually the first test I write when starting a new project. Regardless of platform the test usually looks something like this.

'use strict';

var assert = require('assert');

exports.test_reality = function(test) {
    test.equals(true, true, 'true should still be true');
    test.done();
};

using NUnit.Framework;

namespace Simple.Data.SqliteTests
{
    [TestFixture]
    public class RealityTests
    {
        [Test]
        public void true_should_be_true()
        {
            Assert.That(true,Is.True);
        }
    }
}

This lead to a couple zany one line zingers on Twitter and Facebook. I even had some one suggest that I was ripping off customers by writing such code.

WE sure do treat our customers like suckers. Let $5000 HTML buttons live on! Aeden Jameson

That little jump to conclusion was pretty surprising. But I moved on and continued working on what I was working on that day. A few days later I got an email from a former colleague.

Sometimes you tweet things (like your boilerplate JS test the other day) that I wish you'd blog about. Go into what inspired that test, why it's still part of your bootstrap, etc...
#creepyrandomemails
-JM

So I promised JM that I would blog about the reasons why reality test is the first one I write.

When I am bootstrapping a project, I like to start building out automation from the beginning. With .NET, this is usually a psake based build script. You can see an example from the Simple.Data.Sqlite package I was working on a while back. In node.js, I'll start with a Jake based script. You can see an example here from a project we created during a node bootcamp.

The goal of this automation is to perform builds, testing, packaging and other types of tasks that developers do on a regular basis in a project in a reapeatable known way. How do you know that the source you have on your local machine is good enough to check in? Run the script, if it passes commit it.

So when I am setting up my basic project structure and automation, I like to have at least one unit test ready to run. This allows me to test the automation script and ensure failures in tests cause failures in builds. In .NET I want to confirm that the compilation step fails properly and the unit tests fail properly. In node.js, I want to ensure that linting errors fail as well as unit tests.

All of this can be done before writing a single line of production code. If you are running a continuous integration server, you can set it up to run your script as well on each check in. How many times have you had a build fail in CI and have no idea why or no way of troubleshooting the issue locally? By having the automation locally and having the CI use that automation, you avoid that problem altogether.

All of this may seem obvious to some folks, but some see it as just a waste of effort. I hope I have explained well enough why I do it for you to at least get the point.

If you want to read up on some of these techniques, I highly recommend the book Growing Object-Oriented Software, Guided by Tests otherwise known as the London School of TDD book.