Category Archives: Process

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.

Sure you’re agile, what about your QA department?

For the past 14 years I’ve been a software developer for money, I’ve noticed a trend. The QA department finds the most bugs towards the end of the release cycle. Even when I’ve worked in departments that are supposedly following an iterative development process.

A lot of the “bugs” revolve around “fit and polish” issues. Making sure the font and wording is correct in all locations. Making sure the application looks and behaves the same across all platforms,browsers in the case of web applications. Most all requirements documents or stories include a note for the QA department to perform these checks well in advance of the final launch, yet these bugs always seem to come up and they usually are not regression bugs.

The places that follow an iterative cycle I’ve found don’t really deploy after each iteration to any meaningful customers. They are all still tied to the “big launch”. I think that getting the product into the hands of people who ACTUALLY care about it, rather than the ones that are just concerned about the launch, is crucial to delivering a high-quality product.

I’m wondering if the traditional QA department is a relic that we need to get rid of? If we move all of the testing/bug finding to the interation and fix them immediately, isn’t QA relegated to mainly verifying bugs reported by customers/users?

So the question is: How do we get QA more involved in the process?