There’s one golden rule of software development.
Code spends longer in maintenance than it does in development.
In other words, you spend a short while writing code and much longer reading code.
Where, by reading code, I mean scratching your head, gently swearing under your breath as you wish great harm upon the idiot that wrote this. When you know full well, that idiot was you, three weeks ago.
Of course, you’ve got the specification that the client gave you. That 200 hundred page Word document, with every feature painstakingly mapped out in eye-gouging detail.
Only one problem.
It’s out of date.
As soon as you started development and the client saw how it worked on-screen, they started sending in the change requests. Via email. Or on the phone.
No-one bothered to update the Word document. Why would they? There’s too much to do just to get the thing shipping relatively bug-free.
Which is where the first, and most important, aspect of Test-Driven Development comes in.
TDD is dull.
TDD is documentation.
TDD is executable documentation.
If you make a change to your code without making a change to the tests, the tests will fail. You then have the choice to either keep the tests failing or to update the tests. When you’re under the cosh, it’s very tempting to do the former. And believe me, I’ve done it. I’ve also come to regret it 100% of the time.
Take the time to update the tests.
Even though your boss is staring daggers at you. You’ll thank yourself in three weeks, three months, three years time.
Your test suite is living, breathing proof of what your application is supposed to do.
It’s that your latest change hasn’t broken any previously working functionality.
It’s measurable, living, breathing proof that you know how to do your job.
Pretty good, huh?
So how do you write this executable documentation?
Well, that’s the trick, isn’t it?
Click here to read the next part in this series … (or sign up below to get weekly updates along with a free Ruby on Rails security checklist)