Heikniemi Hardcoded

Why CS students should do TDD

If you are a Computer Science student, take heed:

When you're about to take on an assignment that takes more than two hours to implement, do Test-Driven Development. (that doesn't mean you couldn't use TDD in smaller assignments if you feel like it)

First of all, what is TDD? It is a philosophy that encourages you to create runnable tests before you write code that they test. Of course, the tests won't even compile, but the mere act of writing them forces you to think about your code and its interface - "How would I go about using this B-tree class I'm about to implement?".

TDD documents often refer to sophisticated unit testing frameworks to support automated testing, but forget about that for now. Focus on the testing. Write console applications that do stuff like if (MyTools.Sum(3, 5) != 8) throw new Exception("Sum is incorrect.") for all your relevant methods. If you write more complex stuff, such as a linked list, write tests that insert some items and then read them out, verifying that everything works as you expected.

Now, why?

• You're about to write code that you're unfamiliar with. To be honest, it is likely you have never written an application of this size with this technology before.
• You have a desire to get rid of the application as soon as possible. This means that you, probably a reasonably inexperienced programmer, will make many mistakes in a hurry. It also means that every uncovered bug will slow you down seriously.
• University-level assignments in particular often require an academic pedantic attitude. Such attention to detail is often best left to a computer. You couldn't check for all the details anyway.
• If you're implementing your first data structure / algorithm / whatever, it is likely that you're partially copying your code out of examples and text books. Doing that, you often skip a critical step in understanding. That slip won't save you time, trust me. Doing TDD will force you to understand what you're coding, which will save great amounts of time at a later phase.
• Since just writing tests will be somewhat boring (at first), TDD will encourage you to test the application more often. And passing even a minimal test suite will encourage you to code more.
• Unit tests tend to pinpoint errors rather exactly (at least compared to C++ segfaults and other hard-to-debug exceptions).
• Assignments often require documentation and testing (eww!). It's easier and considerably less frustrating a task when done during the coding. And saves a lot of late-deadline hassle, by the way.
• Good unit tests score well.

So: Write a small chunk tests, then write (or copy/paste) code. Fix the code until the test passes. Then repeat until you're done. If you discover bugs not uncovered by your tests, write a test that fails because of the bug before fixing the bug. That way you'll never fall for that particular trap again.

Most of the reasons above can be used to argue for unit testing in professional programming as well. However, students should consider TDD doubly because: a) TDD saves lots of personal time and students suffer from no corporate friction to offset the savings, b) they are generally unfamiliar with what they're doing and c) they lack the general experience required to guess the location of errors, thus resorting to time-consuming WriteLine-style debugging.

If you try it and like it, learn to use a proper testing framework. It's easy when you already have the TDD mindset ready, and any automated testing environment will make your coding yet easier - even when you move up to professional coding one day. And yeah, it looks good on your CV. And we need more programmers that have been trained to think about testing and their mistakes right from day one.

Posted by Jouni Heikniemi at October 29, 2006 10:40 PM
Misc. programming