Test-driven development

A lot have already been said about Test Driven Development (TDD) by a lot of people, but I'd still like to add my 0.02paisa.

We have an internal requirement of checking in UnitTests along with the product code and the code coverage for the unit tests needs to be high. Most of our developers have over 85% code coverage.

In my sources I decided to try out TDD. I used the following steps

  1. Write the method's prototype so that it matches the design doc and throw a NotImplementedException in it.

  2. Write unit-tests in Visual Studio Team System unit-test framework. I try to cover all the requirements, even the ones required for negative testing like pass an invalid handle and catch an ArgumentNullException and verify that the correct argument is mentioned in ArgumentNullException.Param.

  3. After that  I run the tests. All the tests obviously fail with lots of X marks.

  4. Then I go about fixing each of the test failures by adding the functionality in the code.

  5. After each fix (or couple of them) I run the tests and the red marks keep changing into test passed green ticks.

  6. Once I'm done, I run with code coverage and then add more tests if required to cover the blocks which were not touched by the tests.

Even though the system looks simple it has helped me enormously by catching multiple bugs at the beginning. Even trivial tests like tests for GetHashCode and operator overloads found issues 🙂 The fun in seeing all those X marks disappear one after the other brings in a childish zeal to get them done even faster.

The other goodness is that after every code change later I can easily fire these tests for sanity check.

Comments (2)

  1. Sam Judson says:

    Generally with proper TTD you write a single test (that fails) then write the code till it passes. You then write the next test, and modify the code till it passes. This means you never write more code than you need.

    But glad to see you’re having fun with TTD.

  2. William Stacey says:

    I saw/heard something good on c9 other day. No expert, but this made sense. In TDD, your "tests" are not quality tests (in the normal test sense), they are only *Programmer tests. So don’t write all the tests you can think of as that is what Q testing is for and not the goal here. Actually, "Tests" is probably a bad name as it leads to this confusion. Maybe a better name would be "code drivers" or "code harness" or something.

    Also, start by writing the code you want the User to write. After happy with that, make your api and objects "work" using that code. Then TDD as normal. As we all think different, there probably is not magic formula, but that seems to make sense to me. Don Box posted something about Chris Sells using this approach too.

Skip to main content