I’m starting to get into test driven development.
Test driven development has been advocated in the Rails community for some time (its core to the “Agile” coding methodology) but to be honest I’ve not bothered with it much. I am guilty of getting some code out to hit a deadline and looking to worry about writing the unit tests later. Of course, in the Rails community, that tantamount to admission of a most heinous crime. However, I’m currently reading this: “Clean Code” by Robert Martin and I’ve been persuaded by it to look at test driven development again, and I’m finding it really useful.
Basically the concept is that you write the unit test code first and then write code that satisfies the test. So before you write a new method, you write the code that tests the method’s functionality.
One of the key things the book advocates is that you make sure the test does not work before you start to write the object code. That sounds a little silly perhaps, but I’m finding it helps me make sure the object is working how I expect it to before I start adding code. It gives me a starting point. Then if I add code and the test fails, I know if that is the same failure I got originally or something has changed. It also ensures that I’m not just hitting a pre-existing fault.
By far the greatest benefit is that you know your unit tests work, because you are using them all the time. That makes refactoring less daunting, which supports the concept of reviewing and improving item names, and simplifying code, to make your code more readable and therefore easier to manage. The idea being that your first coding attempt will not be as good as your second or third itteration, so you need to be able to refactor easily to improve the code as you use is.
I’m also finding that I’m being more structured in my testing. When I create a new object or functionality I used to fire up a console and play with the object there. That meant that those tests were not saved. Now I user my unit test which means that each “good test” I use gets written into the unit test and I can use it again. Also if I find a bug, I write the test that replicates the bug before I fix it. That means my unit test gets better as the bug probably indicates that I’d missed something in my test. Then I feel more confident that I’ll be able to catch the reappearance of the bug if such a thing happens or be able to spot a related bug earlier.
Anyway, I thought you may find my ramblings of interest. If you fancy a read, I do recommend “Clean Code” by Robert Martin. He’s a Java programmer, so most of the examples use Java. However, my Java experience is very limited and I have still found it a very interest read.
—–
Update. I’ve just had a great example of why running the test to make sure it fails before you write the code is important:
I wrote a new test method and ran it, but got a pass! When I checked the new test method, I realised I’d forgotten the ‘test_’ prefix to the method name – so the test wasn’t being run with a normal test. That could have been difficult to spot after I wrote the object code because the test result would have been a pass!