If you read my blog at all, you know that I’m passionate about test-driven development. A few months ago, I announced that I was developing a TDD training course called TDD Boot Camp that will teach you everything that you need to know to do test-driven development on real world .NET projects.

I currently have two upcoming events scheduled: July 13-15 in Columbus and August 18-20 in Detroit. You can find out more details on what we’ll cover and how to register at the TDD Boot Camp website. If you can’t make any the events or if you would like me to come to your company, send me an email and we can work something out where I can come to you.

If the whole idea of test-driven development is new to you, or you’re not sure why you should care, come to the Path to Agility conference in Columbus on May 27, where I’m doing a talk on Test-Driven Development In Action. I’ll show you how TDD works and how it can help you deliver IT projects with higher quality, lower maintenance costs, and more peace of mind. Actually, you should go to the conference either way, because there is an excellent lineup of sessions for anyone involved in IT.

This weekend we did some live TDD at the Software Engineering 101 event and broadcast it over LiveMeeting, which was a lot of fun. However, some people have posted solutions (here and here - see first comment) on how they solved the Greed scoring problem without using TDD.

I think you missed the point. The point was to help you learn the TDD thought process and how to put TDD into practice. There are lots of benefits to TDD, and I’ll use these non-TDD examples to illustrate.

How do you know your code works?

Those of you who solved the problem without TDD probably did some sort of manual testing in order to prove that your code is working. You could probably do that with a simple example like the one we had (there were only a few scoring rules). But what happens as we add rules (and in real life we’re always adding rules) and you have to manually test 16 rules? For the record, I took the solution posted here and ran my tests against it.

Tests are documentation

Tests document what the code is supposed to do. Since we wrote our test methods as sentences that read like English, you can figure out the rules just from reading our tests (as you can see in the image above). This is not documentation in Word format which becomes stale, this is living, breathing executable documentation of what the code is supposed to do.

Readability is important

I feel that the solution that we ended up with was very readable. Here is our implementation code:


public class GreedScorer
{
    public double Score(params Die[] dice)
    {
        var score = 0;
 
        score += ScoreASetOfThreeOnes(dice);
        score += ScoreASetOfThreeTwos(dice);
        score += ScoreASetOfThreeThrees(dice);
        score += ScoreASetOfThreeFours(dice);
        score += ScoreASetOfThreeFives(dice);
        score += ScoreASetOfThreeSixes(dice);
        score += ScoreEachOneThatIsNotAPartOfASetOfThree(dice);
        score += ScoreEachFiveThatIsNotAPartOfASetOfThree(dice);
        return score;
    }
 
    private int ScoreASetOfThreeOnes(Die[] dice)
    {
        if (dice.Count(die => die.Value == 1) >= 3)
            return 1000;
        return 0;
    }
 
    private int ScoreASetOfThreeTwos(Die[] dice)
    {
        if (dice.Count(die => die.Value == 2) >= 3)
            return 200;
        return 0;
    }
 
    private int ScoreASetOfThreeThrees(Die[] dice)
    {
        if (dice.Count(die => die.Value == 3) >= 3)
            return 300;
        return 0;
    }
 
    private int ScoreASetOfThreeFours(Die[] dice)
    {
        if (dice.Count(die => die.Value == 4) >= 3)
            return 400;
        return 0;
    }
 
    private int ScoreASetOfThreeFives(Die[] dice)
    {
        if (dice.Count(die => die.Value == 5) >= 3)
            return 500;
        return 0;
    }
 
    private int ScoreASetOfThreeSixes(Die[] dice)
    {
        if (dice.Count(die => die.Value == 6) >= 3)
            return 600;
        return 0;
    }
 
    private int ScoreEachOneThatIsNotAPartOfASetOfThree(Die[] dice)
    {
        if (dice.Count(die => die.Value == 1) < 3)
            return (dice.Count(die => die.Value == 1) * 100);
        if (dice.Count(die => die.Value == 1) > 3)
            return ((dice.Count(die => die.Value == 1) - 3) * 100);
 
        return 0;
    }
 
    private int ScoreEachFiveThatIsNotAPartOfASetOfThree(Die[] dice)
    {
        if (dice.Count(die => die.Value == 5) < 3)
            return (dice.Count(die => die.Value == 5) * 50);
        if (dice.Count(die => die.Value == 5) > 3)
            return ((dice.Count(die => die.Value == 5) - 3) * 50);
 
        return 0;
    }
}


Look how readable our code is. Read the score method. Notice how it tells you exactly what it’s doing. Contrast that with one of the other solutions:


static int Score(int[] numbers)
{
    int valueToReturn = 0;
 
    for (int numberIndex = 0; numberIndex < numbers.Length; numberIndex++)
    {
        switch (numbers[numberIndex])
        {
            case 1:
                if (
                    (numberIndex + 1 < numbers.Length && numbers[numberIndex + 1] == 1) &&
                    (numberIndex + 2 < numbers.Length && numbers[numberIndex + 2] == 1)
                   )
                {
                    valueToReturn += 1000;
                    numberIndex += 2;
                }
                else
                {
                    valueToReturn += 100;
                }
                break;
 
            case 5:
                if (
                    (numberIndex + 1 < numbers.Length && numbers[numberIndex + 1] == 5) &&
                    (numberIndex + 2 < numbers.Length && numbers[numberIndex + 2] == 5)
                   )
                {
                    valueToReturn += 500;
                    numberIndex += 2;
                }
                else
                {
                    valueToReturn += 50;
                }
                break;
 
            default:
                if (
                    (numberIndex + 1 < numbers.Length && numbers[numberIndex + 1] == numbers[numberIndex]) &&
                    (numberIndex + 2 < numbers.Length && numbers[numberIndex + 2] == numbers[numberIndex])
                   )
                {
                    valueToReturn += 100 * numbers[numberIndex];
                    numberIndex += 2;
                }
                break;
 
        }
    }
 
    return valueToReturn;
}


To me, this code is not very readable. If you had to implement a new rule in this method, it would be hard to do (plus you have no tests to tell you that you broke an existing rule).

The point of this exercise was not to find a clever way to solve a brain teaser. If you want to do a brain teaser, try and write code that will output a Fibonacci sequence using one LINQ expression. That’s the kind of geek stuff that you might do at night for fun. But when you’re writing real code, we care about things like readability and maintainability. When you’re writing implementation code, use common language and write methods whose names tell you what they do.

TDD leads to well-designed code

As we were writing our first test, our test told us that we needed some class that would score the Greed game. So we named it GreedScorer, which does exactly what the name intends. This class will most likely end up following the single responsibility principle because we gave it a very specific name.

But you guys took so long!

We weren’t trying to finish as fast as possible. We were not doing a coding competition. We were practicing and learning the TDD mindset and trying to explain things as we went. As you get better at TDD, it becomes more natural and you learn tricks that help you go faster (for example, sometimes writing a whole bunch of tests, watching them all fail, then making them all go pass is faster than just writing one test at a time and making them pass one at a time).

The bottom line is that we came out with some good, readable, maintainable code (with props to Sirena who helped write it). We were able to prove that our code is working. We don’t have any code that we don’t need. We could easily respond to change and implementing new scoring rules would be pretty easy. Implementing the Score method was fairly easy because we were building it incrementally (solving lots of little problems is easier than trying to solve a big problem all at once). This is why we do TDD!

Thanks to everyone who tuned in to watch our live TDD session. Here is the completed code that we ended up with. If you want to try it for yourself, you can get the rules for the Greed game here.

Here are some other “kata” exercises that you can use to help with your TDD practice. These are other simple examples similar to the Greed game.

String Calculator
Bowling scoring
Tennis scoring

Happy testing!

If any of you have tried to learn test-driven development, you’ve probably discovered that it is not easy to learn. It’s not something where you can just go read a book or find a few good blog posts and start doing it tomorrow. You have to learn to how to write tests first, how to use testing frameworks, how to write testable code, how to do dependency injection, how to use mocking frameworks, and on and on.

People have asked me for advice on how to learn TDD and I really haven’t had a good answer for them. I’ve tried doing lunch and learn sessions on TDD and other people have done half-day sessions on TDD. All of these are good, but there’s no way that you can cover all of the subjects that you would need to understand in order to do TDD on real world projects in such a short amount of time. Sure, there’s definitely value in these sessions, but when I did my lunch and learn session on TDD, I felt like people went away feeling more confused about all of the stuff that they just realized that they didn’t understand.

Which is why I’m developing the TDD Boot Camp, a comprehensive, three day training course that will cover everything that you need to know in order to do TDD on real world .NET projects. It will be very hands-on with a lot of coding exercises that will help you understand all of the hows and whys of test driven development in .NET. My goal is to teach all of the concepts, tools, and techniques that you need to know to do TDD so that, with some practice, you will effectively be able to do TDD (and hopefully teach others how to do it too!).

I’m working on scheduling some events, so keep an eye on the website as I get things set up. I can also come out to your site if that would work better. Hopefully this will fill in the TDD learning gap so that more people can start realizing the benefits of test driven development.