Floating Octothorpe

Test driven development

Test driven development is a concept that's been around for quite a long time now. The key principal is software tests should be written before software. Kent Beck is often credited with creating test driven development, however he claims only to have rediscovered it:

The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I'd written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, "Of course. How else could you program?" Therefore I refer to my role as "rediscovering" TDD.

This post is going to go over some of the background to test driven development, and will hopefully be followed up with a future post on using the Python unittest module to do test driven development in Python.

Developing without tests

One of the most common approaches to development looks something like this:

Diagram showing a simple
    development cycle

Certainly when I initially learnt to program I would regularly write small sections of code, run the code with temporary print statements, debug any errors, then go back to writing the next section of code.

This approach is certainly intuitive and works well for small sections of code. Unfortunately as projects get bigger a few problems start to creep in:

Adding tests

To address the issues above you can start writing tests. In theory you could just write manual tests and run them yourself, however this quickly becomes time consuming, and repeating tests manually is no fun. To avoid this test cases can be automated with a test framework like the unittest module in Python.

In essence automated tests are just code which programmatically checks the code you're working on works as expected, however it's worth learning the terms below if you're new to automated tests:

Note: the definitions above were taken from the Python unittest docs.

When I initially started writing automated tests I would normally do something similar to the following:

Diagram showing a
    simple development cycle, followed by writing tests

This is fairly natural because the initial development model remains the same, and tests are only introduced after an initial version of the code is ready. Unfortunately there are a few problems with this approach:

Writing tests during development

As the name implies, in test driven development test cases are written before developing the code to pass the test case. Initially a test case is written and executed to confirm it fails; code to pass the test case is then written; and finally the passing code is refactored before writing the next test case:

Diagram showing the main steps in a
    test driven development cycle.

Unlike the methods above, test cases are written during the code development cycle. This has a few advantages:

Unfortunately there are also some disadvantages associated with test driven development: