By Trevor Baca, VP Software Engineering


How do you keep old code from breaking when you write new code?

The answer is, and has always been, the running of a regression battery of tests. If you have custom classes in your code that, for example, are supposed to allow for multiplication by positive numbers and zero but not by negative or imaginary numbers, then writing a couple of tests to make sure that multiplication by positive numbers and zero work is the way to go. Even better, include a couple of tests to make sure that multiplication by negatives, imaginaries and other types of number don't. As you write more code, write more tests. The tests together constitute your regression battery. Then run your regression battery and make sure your tests all pass at important times. Such as before any major or minor release. And preferably at lot more frequently than that, such as before committing new code to the repository. A good regression battery is a requirement for a good team.

And now a small distinction in the times at which developers write new tests for inclusion in the battery is having big consequences in the world of software development. Enter the notion of test-driven development.

Test-driven development (TDD) helps us develop reliable code faster by putting testing at the center of the process. We've been migrating more and more of our development at Jaduka and NetworkIP to a TDD way of doing things. And the results have been exceptional.

So what is TDD? Take a look at this recent post from molecular biologist and Python enthusiast Titus Brown.

TDD asks that we write our tests as we go rather than at the end of the process. Given that almost all recent software development models are iterative and incremental, this makes good sense. How often does testing get squeezed in at the very end of a project? Too often, of course. And authoring test cases as we go can help considerably.

Supporting the different Jaduka APIs requires an approach to development that prizes consistency. Once any API vendor releases new methods, the public interface to those methods needs to stay pretty much the same. Because users like it that way.

But working on the back-end systems and networking code that makes Jaduka run requires a different set of tools. And a very important one of those is turning out to be TDD.