How do you start a new project with TDD?

Bobby Johnson (@NotMyself on Twitter) wrote a post detailing how and why he “tests reality” when he starts a new project and gives two examples of what he means.

node.js:

'use strict';

var assert = require('assert');

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

C#:

using NUnit.Framework;

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

At first glance, you look at those and think they are silly because all they are doing is testing that the test framework is working correctly. But Bobby has a different reason for including them.

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.

That’s a valid point, however this is more of a configuration test of your infrastructure. I personally wouldn’t write a test like this, I’d want the test to have some value before I committed it to the main repository or build/CI server. I strongly feel that developers should use the same build procedure on their desktops to build the application as they do on their CI server. IDE’s like Visual Studio abstract away the building of the application, so we often have to write scripts, rakefiles, psake files, whatever to do all the things that Visual Studio doesn’t do when it builds your application. Things like running the tests and reporting the results, building an installers or setting test/staging/production values in config files. I like to have a repeatable build system setup for projects I’m working on so I tend to re-use scripts or keep it really simple. Which means that I have confidence that I have configured the build script correctly so that it will work properly when I put it in my CI server. Which allows me to start focusing on the design of my application sooner.