Thursday, September 1, 2011

The irony of not testing

Some time ago I wanted to do something with jQuery. But our customer was still using a really obsolete version: 1.1.3.1 that has been released in 2008. At that time the last stable version was 1.6 and the functionality I needed was introduced in jQuery 1.3. As I had no intention to write something that has been already written (and fixed multiple times over its existence) I asked the the leading programmer of this project if there would be a slight chance of replacing it (jQuery) with a newer version.

The answer was simple: "NO". As strange it may sound I kind of undestood him and it wasn't a suprise for me. It was just a sad realization of the truth. To change the jQuery library I needed to upload it into the core module, that has then been referenced by 9 other big modules (that depended on him). And as NONE of these 9 modules had automated tests of their behavior, no one would know if this change would introduce some bugs or not (they already had workaround and fixes for the old jQuery version and god knows how it would interact with the latest version). So if you look at it: my small task/requirement could have killed all 9 modules that have been nicely working for at least 3 years (and it would require regression tests for EVERYTHING which was extremely costly).

The irony was that the lack of useful tests might forced me into introducing some custom code that was not mature enough (from performance and memory consumption view) and probably buggy (even with some testing) instead of just using some standard code that has been proven with time and repaired/maintained constantly.

The lesson learned from this is: test your code as without it your code might become so big that the task of testing will take a whole year for you (because you need to learn all the business logic behind it to see that this strange behavior is the correct one). As without tests : you might be unable to upgrade your existing libraries and will be forced to create custom workarounds for something that has been already done by somebody else. And in comparison to your code the existing one might be more performant, mature AND under active maintenance.