Testing Times

When we develop software we prefer to use agile methodologies. A key component of these is the idea of test driven development, which we’ve been using for fifteen years.

The basic idea of test driven development (TDD) is that tests are written before the source code which satisfies those tests. Indeed, in a pure TDD view, source code is only written to satisfy tests. In this way, you can ensure that you don’t have code which you don’t need, that the code you do have works as expected, and as a rather splendid by-product, you also have a working specification of what that source code should do.

As you make changes to the system, you can check that you haven’t inadvertently broken something. Before you check any code in, you run the tests to make sure that everything still passes.

With all these advantages, why would somebody not use TDD?

Well, like all good things, it is possible to overdo TDD. Some organisations insist on 100% test coverage (which you have to work at, even if using a pure TDD view where source is only ever written to satisfy a test). Quite apart from the excessively extensive test code generated by a 100% test coverage rule, there is also the argument that your system becomes too brittle, and resistant to change.

After all, agile methodologies embrace change, and many techniques exist to make processes and decisions as nimble as possible. If, however, your source code is hooked up to a test behemoth, with every line tested to be working as expected, then it is going to be difficult suddenly to change aspects of that system, without first picking apart the tests.

So, our strategy is to use TDD, and make sure that our code is defined and verified by test code. However, we don’t insist on unusable levels of test code where it is really not needed. Our unit tests focus heavily on what really needs to be tested.

In order to ensure that the software is completely tested, we also use behaviour driven development. This tests the code at a much higher level, often at the level of user expectations, and could be considered a form of integration testing. Again, a result of this process is a functional specification of the system.

All of these processes ensure that we can provide you with software of the finest quality!