Maybe this is why developers don’t care much about testing

January 2nd, 2012

I’m a huge fan of TDD, and one thing that is really frustrating is when I’m working with people who either don’t know how to write unit tests or don’t agree with the idea of writing unit tests. This is especially true in a static language because those people will design the code in a way that prevents me from writing tests.

Why is it that so many developers don’t care about testing? Most developers that I’ve worked with, whether I agree with their ideas or not, take pride in their work and generally care about their job.

I think that this goes back to the traditional divide between development teams and QA teams. On most teams, there is always pressure to get things done faster. In order to get things done faster, you have to either cut something out or get better at what you do. It’s much easier to cut something out, so inevitably the team will do what they can to cut development time. This means cutting out unit testing (or not taking the time to do it in the first place). Once you cut out unit testing, the next thing you throw out is good design principles and just get it done as fast as possible.

We all know that if you don’t write unit tests and you just throw in spaghetti code to get something done that you’re going to have a lot more bugs. It takes time for QA people to find bugs, reproduce bugs, write up bugs, and retest bugs. But why should the development team care? They were just told to go faster. Who cares how long it takes the QA team to test the application? Why does the development team care if it takes an inordinate amount of time to regression test the application?

The QA team knows what is going on, so they don’t trust the developers. They know that the developers are likely to write bugs, so they will need to be more thorough. The problem is that sometimes this means doing an inordinate amount of manual testing (which may or may not be possible).

This is what happens when development and QA are separate teams that don’t work closely together. Each one is only looking out for their own interests, not the interest of the project as a whole. In my opinion, it makes no sense to do it this way, but this how it’s done in many companies.

On my current project, we have broken down the walls. The QA team and the development team report to the same manager. The developers, BAs, and QAs sit together in the same area. Before we work on a feature, we all sit down together and decide what will be tested with unit tests, what will be tested with automated acceptance tests, and what will be manually tested. Because we’re all on the same team, I (as a developer) care about testing just as much as anyone else on the team. There’s no reason for me to not care about testing. Don’t I want the app to work too? If I write crappy code, it’s going to take longer for the team to get things done. If I don’t help automate regression testing, it’s going to take the team longer to manually test everything. I don’t want either of these, so I’m going to help out. The QA team is starting to realize that they can trust our automated tests (which they’re not used to), and we all agree that in the future they will do much less manual testing.

Because we’re on the same team, we’ve enabled developers to care about testing. If we want to get things done faster, I want to make sure that I automate as many tests as possible so that QA doesn’t have to manually test them. I might even pitch in to help with manual testing when that time comes. In the end, we end up with high quality software delivered in less time because we have very few bugs and we will test things in the most efficient way possible.

Why do we group our tests by file?

January 2nd, 2012






describe "When completing an order" do
  it "should set the status to In Process" do
     # test code here





  • I can see what tests exist for a given business function
  • My tests document business functionality instead of documenting a class



A TDD success story

August 1st, 2010










Reducing the cost of change

July 30th, 2010







Automated Testing





Clean Code




Tests Are Documentation



Build Iteratively



Always Be Aware of Change


Discounted rates!

May 5th, 2010



How to use Rhino Mocks – documented through tests

March 12th, 2010



A response to the SWE101 attendees who tried to solve the TDD problem without TDD

March 2nd, 2010

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.

failing test

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;
                    valueToReturn += 100;

            case 5:
                if (
                    (numberIndex + 1 < numbers.Length && numbers[numberIndex + 1] == 5) &&
                    (numberIndex + 2 < numbers.Length && numbers[numberIndex + 2] == 5)
                    valueToReturn += 500;
                    numberIndex += 2;
                    valueToReturn += 50;

                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;


    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!

The business value of test-driven development

January 27th, 2010

Most businesses are creating software for one primary reason — to make money. In order to make money, we need software that meets the needs of the business and can be developed and maintained in a reasonable amount of time with a high level of quality. Test-driven development is a discipline that will help you achieve these goals.

Test-driven development involves writing automated unit tests to prove that code is working. The test code is written before the implementation code is written. By writing the tests first, you will know when the code is working once the tests pass. Test names are written as sentences in plain English so that the tests describe what the code is supposed to do. Over time, you will end up with a large suite of automated tests which you can run in a short amount of time. These tests will prove to you that your code is working and will continue to work as you modify or refactor the code base.

Most software applications are intended to be used for many years, and throughout most of their existence, someone will be changing them. The total cost of ownership of an application goes far beyond the cost of the initial effort to create the initial version of the software. The first release is the easy part — you can build the application from the ground up, you don’t have many hindrances, and developers feel very productive. But as time goes on, productivity tends to decrease due to complexity, developer turnover, poor software design, and any number of other reasons. This is where software development really becomes expensive. So much focus is placed on the original cost of building an application without considering how the original development effort will affect the cost of maintaining that application over several years.

Test-driven development can reduce the total cost of ownership of an application. New developers on the team will be able to change the code without fear of breaking something important. The application will have fewer defects (and far fewer major defects), reducing the need for manual QA testing. Your code will be self-documenting because the tests will describe the intended behavior of the code. All of this leads to flexible, maintainable software that can be changed in less time with higher quality.

Software is intended to deliver business value, and test-driven development will help you write higher quality, more maintainable software that can be changed at the fast pace of the business. Test-driven development will lead to successful software projects and enable you to write software that will withstand the test of time.

Make TDD your meal ticket in 2010

January 27th, 2010




The cost of unit testing

January 27th, 2010

One question that I hear from people who are new to TDD or writing tests is, “How much longer is my feature going to take if I write tests?” This is a valid question. We all have deadlines, so if we have to add something extra to our development process, it better be worth it.

I don’t think I could say it better than this post did, so I’ll just let you read it for yourself.