Schedule and Events



March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com

Thursday, July 05, 2007

GreenBar is the New Black

(Or: My Code Odyssey)

So, I had a big, nasty codebase. No current documented requirements; a few scattered historical documents. New Requirements of: "Make it to what it did before, only add features (A), (B), and (C)."

Now, keep in mind, this is an interface that produces a text file that is used to produce invoices, bills of material, and actual, you know, CHECKS.

The immediate recommendation was a total re-write - but I did not have documented requirements and had a tight deadline. So I would have to reverse engineer the code, figure out what it was doing, and start over.

To paraphrase Joel Spolsky, when you do the ground-up rewrite, it takes you a year just to get where you started, AND you've got a whole new set of bugs.

So, instead, here is my approach:

(1) Create a consistent, repeatable test environment, where the code would produce the same output every time. (Believe it or not, this did not happen in the past, because some of the database code was missing an ORDER BY statement. The output was the same, but sometimes in different order.)

(2) Save a sample test run to disk.

(3) Make Changes to the code to make it more readable, understandable, easier to change, etc. (Entire month's worth of blog posts here.) Extract duplicate code to it's own function.

(4) Run the interface and diff with Number 2 above. If the files are identical, green light. If not, look at the changes from the previous commit to version control, and figure out the problem, and repeat the test run. I used a piece of software called oUnit to do the run and compare.


-----> The codebase is now a few thousand lines of code shorter, I understand it, a maintenance programmer can take over with less of a learning curve, and changes to the code are less scary.

I've also take the code and split up BuildStagingTables from FileGeneration, so that FileGen can run in ten minutes instead of thirty. This decreases my feedback cycle for test runs, which means that if I get a RedBar, I'll have fewer changes to go compare to find the bug.

I got all this finished about the 3rd of July - just in time to enjoy the holiday.

The stress seems to be mostly over, and I'll be blogging again. All for the need of a greenbar ...

(Coming Soon: Details on the code odyssey, and, also, rambling discussions of the value of customer-facing test automation. Don't Miss It!)

No comments: