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

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