I employ TDD/BDD as my software development methodology. I have found over the years that it is the best way of producing good quality, well-designed code. Not only that, when employed with a customer willing to work iteratively, I have found it to be one of the most reliable ways of delivering software that fulfills the requirements the customer actually has and not what they thought the requirements were at the beginning of the project. So, as far as I‘m concerned, all the evidence I‘ve seen and experienced so far suggests to me that TDD/BDD produces the best results.
Not everyone agrees.
There are developers I respect that disagree, people who I‘ve spoken to, people who‘s writings I read and people I‘ve worked with who just do not see the benefits of TDD. And some that are cynical about software craftsmanship in general. None have made arguments that have convinced me that they‘re right to doubt the benefits of TDD. However, I‘m not a fundamentalist, I‘ll listen to arguments and enjoy having my views challenged.
One thing I‘ve noticed about many (not all) of the people that are skeptical of TDD is that they don‘t really understand what it is. A common misconception is that tests are written in advance of production code; that test code for a component is completed before the implementation. It is perhaps not surprising given TDD is referred to as a test-first methodology.
This is not at all how it has worked for me and not my understanding of what the literature on the matter describes. It is certainly not an approach for TDD I would advocate or advise.
As a result of the misunderstanding, some developers find a real barrier to being productive when trying to implement new code employing TDD. This article isn‘t written with the intention of making an argument in favour of TDD or to envangelise in anyway. Hopefully, it will go some way to address the barrier that some experience.
TDD is iterative
To illustrate the iterative nature of TDD I‘m going to write some code. The process whereby this problem will be solved will illustrate how TDD helps us understand the problem and how our solution will evolve. It will also illustrate how the resulting solution can more easily be refactored to provide a cleaner solution by relying on the tests to verify the correctness of the refactored code.
The simple problem in question is – bizarrely – based on an actual requirement I had to fulfil not so long ago. It is to place a sequence of integers from 1 to n , where n is an odd number, in a collection ordered such that 1 is placed in the middle with each successive number placed either side of 1, alternating from left to right.
Getting started
I know it‘s meant to be test–first, but I usually start with a class and a method representing the implementation. I‘m not too worried about the name of either the class or the method at the moment, nor the signature of the method. I can always change these as I go along and further clarify the requirements, usually multiple times.
def sort(count: Int): List[Int] = {
return Nil
}
}
Oh, and by the way, this is going to be Scala. I develop in Java for a living, Scala I develop to keep me sane. Writing software in Scala reminds me why I got into software development in the first place. The requirements are represented by Specs specifications.
So, now we get to the TDD bit, the very next thing we do is create a testcase (or a specification) with stubbed tests (or examples) for the requirements we know of or can easily deduce.
"MiddleOutNumberSorter" should {
"reject even number counts and throw an exception" in { }
"return a list of the same length as the count specified" in { }
"produce 3 numbers in the correct order" in { }
"produce 5 numbers in the correct order" in { }
"produce 15 numbers in the correct order" in { }
}
}
One of the things I like about Specs is the fact that empty examples (or more specifically examples without assertions) will manifest as skipped tests and not passing ones.
One thing you will find when producing these test stubs for business requirements is that it will prompt you to think about what the requirements you have actually mean. If, in fact, you can‘t think of any tests to write it is probably an indication that you either don‘t understand the requirements or they are not well defined. Either way it means that you need to go back to the customer to clarify the requirements.
Fail, fix, repeat
Because they are stubs, none of these examples actually break our code. We‘re going to change that. So let‘s write a test that represents a real requirement. This will cause our (currently minimal) implementation to fail.
var sorter: MiddleOutNumberSorter = _
"MiddleOutNumberSorter" should {
doBefore {
sorter = new MiddleOutNumberSorter
}
"reject even number counts and throw an exception" in {
Array(0,2,4,10,212).foreach {i =>
sorter.sort(i) must throwA[IllegalArgumentException]
}
}
"return a list of the same length as the count specified" in { }
"produce 3 numbers in the correct order" in { }
"produce 5 numbers in the correct order" in { }
"produce 15 numbers in the correct order" in { }
}
}
Ok,now the production code fails the test criteria so we turn our attention to the implementation to address this. We do the bare minimum possible to achieve this. So the implementation now looks like this:
def sort(count: Int): List[Int] = {
if(count % 2 == 0) {
throw new IllegalArgumentException("sort only accepts odd numbers")
} else {
return Nil
}
}
}
“Hang on“, I hear you say “that‘s not going to sort our numbers, not even close”. You‘re right. All this does is satisfy the one requirement for which we have an example.
This is obviously no more correct than it was before in terms of satisfying the end requirements. This is a bit of a difficult concept to get over for non TDDers. Someone on the #java IRC channel once sarcastically said words to the effect:
TDD is wasting time writing code I know is wrong all day.
What it does mean is we can quickly get back to specifying more of our requirements by filling out another stub. So, on to the next example.
var sorter: MiddleOutNumberSorter = _
"MiddleOutNumberSorter" should {
doBefore {
sorter = new MiddleOutNumberSorter
}
"reject even number counts and throw an exception" in {
Array(0,2,4,10,212).foreach {i =>
sorter.sort(i) must throwA[IllegalArgumentException]
}
}
"return a list of the same length as the count specified" in {
Array(1,3,9,15,133).foreach {i =>
sorter.sort(i).size must_== i
}
}
"produce 3 numbers in the correct order" in { }
"produce 5 numbers in the correct order" in { }
"produce 15 numbers in the correct order" in { }
}
}
And back to the implementation, again doing the bare-minimum we can to satisfy the requirement.
def sort(count: Int): List[Int] = {
if(count % 2 == 0) {
throw new IllegalArgumentException("sort only accepts odd numbers")
} else {
return (0 until count).toList
}
}
}
And so we continue until we have an implementation…
def sort(count: Int): List[Int] = {
if (count % 2 == 0) {
throw new IllegalArgumentException("sort only accepts odd numbers")
} else {
val numbers = new Array[Int](count);
for (number <- 1 to count) {
val index = if (number == 1) {
count/2
} else if(number % 2 == 0) {
(count/2) + (number/2)
} else {
(count/2) - (number/2)
}
numbers(index) = number
}
return numbers.toList
}
}
}
...that satisfies the entire specification:
var sorter: MiddleOutNumberSorter = _
"MiddleOutNumberSorter" should {
doBefore {
sorter = new MiddleOutNumberSorter
}
"reject even number counts and throw an exception" in {
Array(0,2,4,10,212).foreach {i =>
sorter.sort(i) must throwA[IllegalArgumentException]
}
}
"return a list of the same length as the count specified" in {
Array(1,3,9,15,133).foreach {i =>
sorter.sort(i).size must_== i
}
}
"produce 3 numbers in the correct order" in {
sorter.sort(3) must containInOrder(List(3,1,2))
}
"produce 5 numbers in the correct order" in {
sorter.sort(5) must containInOrder(List(5,3,1,2,4))
}
"produce 15 numbers in the correct order" in {
sorter.sort(15) must containInOrder(List(15,13,11,9,7,5,3,1,2,4,6,8,10,12,14))
}
}
}
Now I commit this code to version control. It‘s complete, and I can be confident that it fulfills the requirements because they are codified in unit tests. Not only that, those tests provide an invaluable resource to other developers working on the project. They now have code that when run generates a report that tells them in plain English what it should and should not do.
Being a an aspiring software craftsman I want all the code I write to be maintainable, with minimal technical debt. I want it to be sustainable in the longer term, so I'm not entirely happy with the implementation. In general, I want to reduce the number of WTFs per minute to a minimum.
The benefit
Also, I‘m becoming less keen on the imperative style and Programming in Scala promotes a more functional style using immutable objects. The thing is, having been mainly a developer of imperative languages, I'm still learning to code in a functional style – particularly in Scala – and so it doesn't quite come naturally to me yet. Without test coverage, this would be a risky approach. In my attempt to produce more functional code, I might cause it to produce incorrect results. Because I‘m new to FP, I might not really understand why. However, because I produced the test coverage as I wrote the production implementation I have a safety net which tells me instantly if I broke anything.
So after a bit of experimentation and copious runs of the specifications, I end up with the following, far more elegant solution. Although elegance is somewhat in the eye of the beholder, so I don‘t expect everyone to agree :)
def sort(count: Int): List[Int] = {
if (isOddNumber(count)) (0 until count).map(i => numberAtIndex(i, count)).toList
else throw new IllegalArgumentException("sort only accepts odd numbers")
}
private def isOddNumber(count: Int): Boolean = {
count % 2 != 0
}
private def numberAtIndex(index: Int, count: Int) = {
val middleIndex: Int = count / 2
if (index > middleIndex) {
2 * (index - middleIndex)
} else {
2 * (middleIndex - index) + 1
}
}
}
As I mentioned, I'm currently learning Scala and FP, so I'd love it anyone reading this could suggest alternative implementations.
First published on Dec 10, 2010. Last updated on: Dec 10, 2010.
I'm Elwyn Malethan and this is my blog. I am an aspiring 