The proof is in the testing
I am a recent convert to behaviour-driven-development (BDD) and this idea of writing stories and specs before writing code. Before I joined Eden Development, testing was always something that sounded like such a good idea … but I just didn’t have the time! Now I can’t imagine writing any code without tests. The idea seems positively frightening!
Here are some reasons why i have been won over by the test-first philosophy:
1. One thing at a time
Of course we all like to write very small concise functions, don’t we? But even in a small function, there are usually a few different paths that could be taken through it. It is so beneficial for me to think of scenarios one by one, write up the expected outcome, and then write the function a little bit at a time until it passes all the tests.
2. Confidence
Let’s be honest – who wants to go back and manually test all the things that you’ve tested a hundred times before and you’re pretty sure they’re still going to work? I used to be a tester – that was my job – and I couldn’t stand the monotony. But you can never have complete confidence in your whole system unless you have tested all of it. If you have broken something, it’s much better to know sooner rather than later. When you have a complete set of tests to run after every test you can be completely confident in your application.
3. Prove the obvious
Sometimes I’m writing a piece of functionality and I think, “Oh that’s so obvious – I don’t need to write a test for that!” But then I think to myself, if it’s so obvious then I had better make sure that it stays that way. In any case, it may not be obvious to the next person who works on this bit of code. It may not even be obvious to me in a few months time. So I write a test to prove the obvious. If somebody changes it and breaks the test, then they will be forced to think twice about the change they are making.
4. A greater understanding
Step-by-step stories are a wonderful way of understanding a system. Often when I’m coming to a piece of code I’ve not worked on before the first thing I do is work through the story. It may be enough just to read it through to see what happens when, and why. Sometimes I literally follow every step of the story, performing it manually to see for myself what it does. Once I understand what is supposed to happen, I’ll have a far better chance of following the source code. So be kind and write nice stories for the next person who comes along and wants to understand your code.
We write our behaviour-driven-development stories and specs using RSpec, and we are currently converting to Cucumber to run our test suites.