Bugwards Compatible

2018-02-02 • • Comments

Chris Oldwood recently tweeted about “TFW you write some tests for a bit of legacy code before making a change and you unearth a bunch of bugs”

He doesn’t elaborate on what exactly “that feeling” is, but I’ll bet it’s not surprise. Writing tests for code almost invariably shakes something out — perhaps some undocumented assumptions about the inputs; perhaps a failure to match the documented behaviour; perhaps an access violation which will crash the application.

“That feeling” can include relief: the code is legacy code and evidently the bugs have gone unnoticed or at least unreported. Often, any such relief may be accompanied by a sense of wonder. The bugs may be so severe — the code so broken — that the maintainer questions how it ever worked.

“That feeling” may also be dismay, since the legacy code requires changing. If the existing behaviour is buggy but predictable it could well be that clients have adapted to this behaviour and wouldn’t welcome a fix. In other words, the change will have to be both backwards and bugwards compatible. Chris will have to tread carefully.

Such delicate decisions are not limited to the code’s runtime behaviour. It might seem that, once the code is under test, Chris can refactor mercilessly — renaming variables, updating idioms, tidying layout. Again, tread carefully! Make sure the code is under test. Be aware of the differences which reviewers must evaluate. Consider the wider context. Respect the original authors.