Opinion: If you embark on building a major project without implementing some sort of automated testing/regression testing framework along side then you are a fool.

What?

Regression testing is nothing more than a set of automated tests that are written to test certain parts of your code. Tests can be written to test core bits of functionality, or be written to replicate certain bugs.

Crucially, these tests are run automatically – perhaps daily or on code commit – and make sure that core functionality remains functional as your development moves forward, and that known bugs don’t re-surface.

There are numerous test suits out there, but in all honesty you don’t have to be fancy. In my projects I often find myself reusing a test suite I initially put together in an afternoon (and have improved on ever since) and which is far from the most sophisticated bit of software ever written (although it is nonetheless exceedingly powerful if I do say so myself!).

Why?

Primarily, this sort of testing gives you confidence in the code you write.

It requires a little discipline from your team – namely that you write a test as part of your development process as you build out new features or squish bugs – but this actually fits quite nicely into the development workflow (afterall, you have to test your code somehow).

However, once you’ve got into the habit of doing it you can then rest easy to know that a new feature hasn’t silently broken something you wrote ages ago, or that a nasty bug hasn’t resurfaced.

In other words, your code is provably correct – this saves you time, as well as saving you the embarrassment and cost of inconveniencing paying customers.

Tests are also (quickly) repeatable, systematic and deterministic.. unlike the standard “run once and click a few buttons” method of testing adopted by many software developers out there.

An Example

Here’s a personal example of the ass-saving power of having a regression testing framework in place..

A couple of weeks ago I was deep in Latakoo’s server infrastructure making all kinds of performance optimisations to the page loading and database handling code. To get some more data as to where some of the bottlenecks were I performed extensive profiling (more on that later) and added sections of debug to collect statistics on various parts of the system.

All good stuff.

However, one apparently minor change I made had an unexpected and not immediately visible effect of completely breaking the Latakoo API. This API is what all the clients use to get video into our infrastructure, and so had this code change made it through to our production servers it would have prevented anyone from using our service and have cost the company untold $ in lost revenue.

The performance of the API is something that is naturally tested by the regression testing framework, and no sooner had I applied the patch on our test server than I received an email telling me that I had broken the API.

A quick fix later and a potentially costly and embarrassing show stopper of a bug was caught and fixed before anyone else knew it existed.

The moral of the story…

Bugs happen. Software development is hard and even the best of us make honking mistakes from time to time. What matters is that you acknowledge this and have the necessary early warning systems in place to prevent them becoming a serious problem.

All it requires is a little discipline and this is what grown-ups do.

So write those damn tests already!