OK, I am back on the track after enjoying a nice week of (learning) snowboarding out there in the French Alps. So where did I leave you behind? (And by the way: the best for 2012!)Yes, Test-Drive Development. Oops, I did it again! Where did that 'n' go? To lazy to touch the n-key well enough. Reset and type it again, Sam: Test-Driven Development.
Did you notice it in my previous post?No? So it did suffice. My text past the test (being your pair of eyes and that's "behind it").Yes? It did not suffice. My test clearly did not pas the test and so it should be fixed (which I in fact already did a couple of days ago).
TDD in a nutshell! Most probably too tiny a nutshell for some of you to understand what TDD is all about and therefor, in this second part of the intro, I will elaborate a little bit more on what TDD actually is. To save you reading the various references I provided in the first part. Although, on second thought, I might not be doing you a favor "saving you the reading" as Kent Beck's book is really worthwhile reading, if you want to have a good laugh. It is really hilarious; take my word.The basis of TDD is very simple and consists of the following 2 rules. 2 Rules only? Yep, and this what they are:
As simple as it is these 2 rules entail more than you might guess at first sight.The first rule is actually implying that you first write tests before you write any code. In this each test embodies the requirements your code should satisfy. So your list of tests is an overview of all the requirements, or you might call it a transformation of the requirements. Now one of the major consequences of this rule is: no requirements (i.e. no tests), no code, whereby we will not have any code that is not tested.The second rule is probably something not very new to us, I hope, as I guess any good programmer is striving to prevent any duplication in the code he is writing. Nevertheless, it turns out a bit different within the context of TDD being an essential part of it. Given the automated tests it's also much more efficient and safer to eliminate duplication.
Or to put in other words:
(1) We transform specs to code by defining tests, being what is called the Test List, (2) we program test and write our code against it only make it pass the test, (3) we build only what is asked for and (4) refactor the code to clean up and eliminate duplication, where the rerun of test ensures that refactored code is still valid.
They make up, what Kent Beck calls, the RED/GREEN/REFACTOR mantra:
Take any of these steps as small or large as you want to and can handle.
In a series of next posts I will illustrate the process based upon the NAVTechdays 2011 presentation of Bas Graaf.