Developer Race-Tech: Continuous Testing

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)! Compare that to the circa 1 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, 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. The comparative tedium of de-clutching, shifting and re-engaging the clutch is just not something a race-driver should need to worry about as they approach 200mph while adjusting the brake-balance lever or switching to a new fuel-air mixture setting via buttons on the steering wheel.

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 equivalent of 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 autospec.

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 level down a menu 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?

Need for Speed

Try it for a while and, like me, even keyboard-shortcut run 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...