Perhaps counter intuitively brakes let you drive fast. Without the brakes we would drive really, really slowly. I believe the same is true of automated tests. Something that looks like it should make you go slower actually lets you deliver code faster. As long as you’re doing the right tests.
Bit of credit where credit is due – this post originated in a tweet from Bryan Beecham:
Brakes let you drive fast. Automated tests let you deliver code faster. #SafetyFirst
Bryan Beecham, @BillyGarnet, 11 June 2013
Brakes let you drive fast
Imagine if you didn’t have brakes in your car. I don’t know about you but I’d drive very, very slowly. So slowly that if needed I’d be guaranteed to coast to a stop quickly.
With brakes I can drive faster. Obviously not all the time. When it is safe I can drive fast. When conditions change I can brake to slow down. It is the brakes that give me the confidence to driver fast.
Automated tests let you deliver code faster
Some people object to automated tests because the tests take time to write. Perhaps an equal amount of time to writing the code for the functionality itself.
For me that time is an investment. It takes longer to get “Dev Done” on the first User Story. But subsequent User Stories get faster. In maintenance mode the automated tests are god send and software spends most of its lifecycle in maintenance mode.
Automated tests provide a safety net. They let developers take risks in terms of new/refactored code. If the change breaks something the developer gets instant feedback. That leads to more changes until the tests run green. When the code is checked in the developer is pretty sure everything is fine. And they can then pull the next ticket.
In the absence of feedback from automated tests the developers have to go much slower. They approach every change with considerable caution. Or perhaps they don’t and knock something out, but there is a good chance that this quick change will cause a fault somewhere else, with resulting debug and fix time.
You have to write the right tests to get the benefit. For example, specify business rules by example and keep the test suite running fast.
My observation is that coding without automated tests starts fast but gets slower and slower as the system gets bigger. Delivery with automated tests starts slow but gets faster over time. Much faster compared to the test-less approach.
This post is part of a series on Specification by Example.