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:
2 Rules
- Never write a single line of code unless you have a failing automated test
- Eliminate duplication
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.
Red/Green/Refactor mantra
They make up, what Kent Beck calls, the RED/GREEN/REFACTOR mantra:
- Write your first test code
- Compile this test code
- This inevitably will fail (RED) because you haven’t implemented anything yet
- Implement just enough to compile
- Run test and see it fail (RED)
- Implement just enough to make test pass
- No more, no less, or as Kent states it: “Fake it till you make it”
- Run test and see it pass (GREEN)
- Refactor for clarity and to eliminate duplication (REFACTOR)
- Repeat from top
- So you will write your next test, i.e. pick up the next requirement as the first one has been satisfied
Take any of these steps as small or large as you want to and can handle.
Note that:
- Little to no need for debugging
- as with each failing test we most probably can easily track the erroneous code
- note that when code fails we can quickly return to previous state of code, given our steps aren’t to big; of course a source control system will be of much help here
- More coding as we have coded tests next to our (production) code, Kent claims that we will end up with smaller and better “product” code, together with automated tests!
In a series of next posts I will illustrate the process based upon the NAVTechdays 2011 presentation of Bas Graaf.
TDD Series Index
- Test-Driven Development in NAV – Intro
- Test-Driven Development in NAV – Intro 2
- Test-Driven Development in NAV – By Example
- Test-Driven Development in NAV – Test #1
- TDD in NAV – Triangulation
- TDD in NAV – Test #2
- TDD in NAV – Test #3
- TDD in NAV – Test #4
- TDD in NAV – ASSERTERROR or IsFalse
References
- Test-driven development (wikipedia)
- Test Driven Development: By Example by Kent Beck
- Test-Driven Development in Microsoft .NET (Microsoft Professional) by James W. Newkirk and Alexei A. Voronstov
- High-Quality Test Automation for NAV Applications by Bas Graaf at NAV TechDays 2011