Old Favourite – Developer Race-Tech: Continuous Testing

The original version of this article appeared on my old blog on 28th April 2010. This version has had some edits…

Gearboxes in competitive motor racing are designed to shift as fast as possible. A competitive race-car has computer controlled, hydraulically activated gear shifts that change gears up or down faster than you can blink (literally)! In Formula One, each shift is so fast that the gearbox systems have been dubbed “seamless shift” gearboxes and can shift gear in around 2-4 100ths (0.02 – 0.04) of a second. Compare that to the circa 1-2 second gear-shift a competent driver takes to manually de-clutch, change gear and re-clutch on a road car. Even automatic gearboxes on road cars can’t keep pace with the rapid gear changes that a race car delivers.

Competitive Edge

The race car is only saving fractions of a second with each accelerated up-shift, but the race-driver changes gear so often per lap and there are so many laps in a race that these fractions of a second can add up to a vital and significant lead over their competitors.[1]
mclaren-mercedes

Set aside the lap-time improvements for a moment from spending at least half a second more on the power per up-shift than with a manual box… The modern F1 driver has much more to do in the cockpit too than the comparative tedium of changing gear [2].

Developer race-tech

Now, in motor racing, such gearboxes are taken for granted. No serious Formula One racing team would put their car on the track without one.

In a world where a lot of software development is for companies competing in the economical equivalent of a race, it seems that development teams aren’t taking full advantage of their own metaphorical millisecond gear-shifts.

There are tools that are a developer’s equivalent of a racing gearbox. The simplest example is background compilation. Other examples are refactoring tools that make widespread changes with a simple key-stroke. What once took minutes or hours with global find & replace or even scripting, we can complete in seconds. IDEs that automatically complete class-names and method names are another example. These are tools that many of us take for granted, like the racing driver and automated gear-shift.

Falling behind

But there are other places where we are still not taking full advantage of the technology. I am still encountering surprisingly few people using continuous testing tools, where tests are run automatically in the background every time a file is saved, and not just the test I’m working on, all my tests. There are a few tools available for this, including Infinitest and ZenTest.

Despite the availability of such tools, I still see many developers using keyboard shortcuts to execute tests. Or, worse, reaching for the mouse, right-clicking, navigating another menu level down and running the tests with a left-click, or worse still, forgetting to run them altogether. I want rapid feedback with minimum friction to obtaining it. Much like background compilation, unit tests should just run, and run often, alerting us when a problem occurs. The easier they are to run, the more likely we are to run them… How much easier could it be than it happening automagically each time we save a file?

Need for Speed

Try it for a while and, like me, even keyboard-shortcut executed tests start to feel like you’re stuck in traffic rather than being in a competitive race to the finish… Or, maybe it’s just me and my need for speed

 

The video is of me on the Silverstone Southern Circuit (part of the F1 GP circuit) taking my UK National Class B Racing License Test in a Nissan R35 GTR – approx 480+bhp, 0-62mph (0-100kmh) in 3.5secs, using it’s double-clutch, paddle-operated gear-shift providing gear changes in about 0.2 of a second. I passed… despite being very cautious on the brakes… and was noticeably quicker than the other person doing their test… which you see towards the end as I pass them 🙂

[1] At the Monaco GP, an F1 driver will change gear around 50-60 times in one lap. Over 78 laps, this adds up to as many as 4680 gear changes over the whole race (up and down-shifts).

[2] The comparative tedium of de-clutching, shifting and re-engaging the clutch is something that a race-driver should not need to worry about as they approach 200mph while adjusting the brake-balance lever, switching to a new fuel-air mixture setting, pressing the KERS boost button and/or deactivating the Drag Reduction System.

 

  • Unlike the race driver who’s gearbox was designed, built and tested by somebody else the developer has to, at least most of the times, design, built and test the test cases himself if he/she is to (re-)use a continuous testing tool. I think herein lies the crux of the problem. A lot of developers do not seem to want to put in that kind of effort for something they either do not do anyway or are content with the test cases they have added to the code.

  • Hi Jean-Paul.

    Firstly, it’s a sad truth that many developers don’t do much in the way of testing their code… and that’s a shame because that means they are not taking responsibility for what they do. 

    Secondly, developers who aren’t bothered about writing automated unit tests or are not running unit-tests frequently are not the target audience for this blog post… This really is targeted at developers who are employing TDD (or an approach that results in frequently writing and executing unit tests).

    Beyond that, I think the direction you’ve taken the metaphor causes it to break down (as all metaphors do eventually)…

    Think of running the unit-tests (something the developer does) as being analogous to selecting a gear (something the driver does).

    Think of saving your files then telling your IDE or command-line to run the tests (something the developer does) as being analogous to de-clutching, moving a gear lever and re-engaging the clutch (something the ‘typical’ driver does).

    Think of each save to a file (something developers do) automatically causing relevant unit tests to be run in the background as being analogous to tapping the up-shift paddle (something a race driver does) automatically causing the de-clutching, shifting of cogs and re-engaging of the clutch in the background. In this part of the analogy, I’m only relating actions of the developer to the actions of the driver… not the internals of the machines they happen to be operating.

    JUnitMax and Infinitest are two plugins that behave just like this. They make the execution of your unit tests as unobtrusive as background compilation… they even run the tests that are most relevant first based on the class you’ve just changed.

    I hope that clarifies my point a little…

    Personally, I write and execute unit tests frequently and the less I have to think about explicitly pressing the keyboard shortcut to run my tests the better… I’d rather it just happen in the background.

    Best,

    Antony

  • Hi Jean-Paul.

    Firstly, it’s a sad truth that many developers don’t do much in the way of testing their code… and that’s a shame because that means they are not taking responsibility for what they do. 

    Secondly, developers who aren’t bothered about writing automated unit tests or are not running unit-tests frequently are not the target audience for this blog post… This really is targeted at developers who are employing TDD (or an approach that results in frequently writing and executing unit tests).

    Beyond that, I think the direction you’ve taken the metaphor causes it to break down (as all metaphors do eventually)…

    Think of running the unit-tests (something the developer does) as being analogous to selecting a gear (something the driver does).

    Think of saving your files then telling your IDE or command-line to run the tests (something the developer does) as being analogous to de-clutching, moving a gear lever and re-engaging the clutch (something the ‘typical’ driver does).

    Think of each save to a file (something developers do) automatically causing relevant unit tests to be run in the background as being analogous to tapping the up-shift paddle (something a race driver does) automatically causing the de-clutching, shifting of cogs and re-engaging of the clutch in the background. In this part of the analogy, I’m only relating actions of the developer to the actions of the driver… not the internals of the machines they happen to be operating.

    JUnitMax and Infinitest are two plugins that behave just like this. They make the execution of your unit tests as unobtrusive as background compilation… they even run the tests that are most relevant first based on the class you’ve just changed.

    I hope that clarifies my point a little…

    Personally, I write and execute unit tests frequently and the less I have to think about explicitly pressing the keyboard shortcut to run my tests the better… I’d rather it just happen in the background.

    Best,

    Antony