« Nation of Verification | Main | Sooner rather than later »

The Value of Automated Unit Tests

I had an intersting hallway discussion with a co-worker last night about unit testing and follwoing coding conventions. The readers digest version is that he is against both of them unless he happens to like them. (Why didn't the get him durring the layoffs? Oh yea, he's a team lead...). His defenses are that (a) he doesn't have time to write them and (b) be tests his code when he writes it. The problem with (a) is that he tops the foosball stats with games played. The problem with (b) is that it is a manual process, and he claims that he doesn't have the problem of unintended consequences because he "takes the time to understand his code." So when confronted with the argument of change of code ownership (which happens here alot, but not with him yet) he says "well then the developer should take the time to understand the code before he changes them." Holy Concieted CMM Level 0 Heroic Effort Batman! That is practically a profession of faith against repeatable engineering process, equvilent in value to the typical high school hackers, who he took the time to slander. I wish I could remember exactly what he said because it was so derogitory to people who wern't as good as he was (apparently he never took the sensitivity training that our ex-VP said he needed in his annual review). This discussion occured while he was packing up his laptop and heading home so it ended with him in a huff leaving.

The irony of this is that this morning I found a perfect example of how unit testing protects against the law of unintended consequences, which he says "good" developers never do. A unit test that I do involving schema validation was breaking. Not only was I fixing the coding conventions in those files but our IT/SCM/Build/Developer guy (layoffs do wierd things to job responsibilities...) was upgrading the tools we use used to build and such (being between release and such) including Xerces up to 2.2.1. Unit tests to the rescue! First I reverted all my edited files, still breakes. Then I use older version of Xerces, still breaks, even the version I had before the upgrades. After some head scratching I descide to revert the whole build tree to the last known good point and run the unit test. It works! (I would have been screaming if it wasn't because that shows there is a SCM hole). So I sync one commit list at a time, and it turns out the point it breaks is when... not my code changed, not when Xerces was upgraded, before both of those even happened. It occured when Xalan was upgraded. It turns out that 2.4.1 ships with Xerces 2.2.0, which has a schema realted bug in it. The way the tools tree was set up the jar loading was taking the xerces jar from xalan ($#@&ing manifest files) rather than what the classpath said. Because of the Automated Unit Tests I was able to narrow down the breakage to a single checkin, and then the "Ah-Ha!" moment came much easier. With the reliable test it took me an hour, but wihtout it I would have beens scratching my head all day over waiting for that "Ah-Ha" to occur. not knowing where the breakage really started. And it wasn't that a bad developer was being a code cowboy either, it was that law of unintended consequences striking again when a seemingly innocent change to the system wasn't so innocent.

IMHO accepting and embracing processes like unit testing is what seperates a Software Engineer from a simple developer or programmer. There is a difference.

About

This page contains a single entry from the blog posted on November 15, 2002 11:34 AM.

The previous post in this blog was Nation of Verification.

The next post in this blog is Sooner rather than later.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33