The next series of blog posts are going to be focused around Test Driven Design, or TDD for short. Take a guess what this form of development is all about…
That’s right, driving development THROUGH tests! What gave it away??
We begin with the holy grail of TDD:
THOU SHALT NOT WRITE A SINGLE LINE OF CODE WITHOUT HAVING A FAILING TEST THAT REQUIRES IT TO BE WRITTEN
Take heed, developers, for breaking this rule will land you in detention with Professor Umbridge, where she will make you write it over and over with her Black Quill until it is etched into the back of your hand, and your long term memory.
There are three steps to test driving your code, nicely summarised by this diagram:
1. Write a failing test. Your tests act as your specification in the project, so pick one behaviour the application SHOULD have, and write a test to assert that this behaviour is fulfilled.
2. Write an implementation to make this test pass in the SIMPLEST way possible, even if this means returning hard coded values! We do this so that our code is almost always unbroken.
3. Last, but most certainly not least, is THE most important step of the whole thing – REFACTOR, paying particular attention to duplication (as this is a good hint for how we can write reusable code and remove the need for the duplication). We should look to refactor ALL code, our implementation AND our tests. Whilst refactoring, continue to run tests to ensure that they’re still passing.
Once we’re done with this stage, we should have code which we would be happy to ship out, so keep it clean at all times. You will most likely not go back to a piece of code once you’ve written it, so if you’re feeling lazy on the day there’s a good chance you’ll leave an awful bit of dirty code in the codebase all the way to production. Then don’t come running to me complaining when, in ten years time, someone looks at it and wonders why on earth any self-respecting developer would have left such an obviously refactorable snippet of code there. Consider yourselves warned.
That’s it! We’re done! Simples! Actually speaking of done, how do we actually know we’re done when we’re TDD-ing? (Yes, I made it a verb – “to TDD” – I TDD, You TDD, She TDDs and so on).
We are done when we can think of NO more failing test cases to fit our specification.
Of course, this in no way means we can’t write further tests as sanity checks to make sure it all works, whilst expecting them to pass. There’s a super special name for this – it’s called testing :). We like testing, we think it’s a very good idea and everyone should do a bit of it… but testing and TDD-ing are different things.
Right, glad it all makes sense. Now everyone start to TDD! Or read on… more details and examples to come.