*I plan to write about the work I do for my company a bit in this space, but until I talk it over with the company’s founders, I’m going to keep my company anonymous. I would very much like to increase our exposure by mentioning it in this space, but they reserve the right to stop me.

I work here in Boston for a small ISV (to use Eric Sink’s parlance). Our product is a tabula rasa J2EE case management system. One feature of our system is an import/export tool, that allows a single case to be imported and exported to/from a standard XML format. We get all sorts of feature gains from this:

- Web Services data exchange capability
- Archiving
- Database memory usage management

It’s also enabled a spectacular way to create a robust testing harness. We have unit tests for features such as log in, opening / closing cases, modifying reference data, etc. that belong to the core application. However, writing unit tests for each individual customer could theoretically cost a lot of cycles in implementation.

On my current project, test pre-conditions and post-conditions typically come in the form of an Excel spreadsheet from our BA. Personally I love Excel; I think it’s one of Microsoft’s real accomplishments that succeeded on its own merits rather than lock-in. BA’s love Excel because its an easy way to organize a table of information.

Well a test pre-condition is simply an import file! All our unit tests begin by importing a case into the application. Similarly, all post-conditions should be observed if the case were exported immediately after processing. So our unit tests capture the result case via export. The process is generic enough that a baseline abstract unit test can cover all generated test cases. So the script writes a JUnit .java file with test() methods based on the output columns.

So if each class of tests can be described in an Excel spreadsheet, then a simple framework to parse a spreadsheet, produce a “before” case import file, an “after” case file, and a JUnit .java file for each row can handle most of the end-to-end testing we’ll need. Advantages to this approach:

1. Extensibility – Each spreadsheet contains a class of tests. Adding new unit tests is as simple as adding a row to the spreadsheet and running a script.
2. Maintainability – Instead of the development staff maintaining each individual test, the Business Analyst has complete control over each class of tests, and can be provided a report on which tests passed and failed. And he/she gets to use Excel!
3. Accountability – I assume JUnit testing needs no justification to today’s developers. But its nice to be able to have the Business staff back you up when you claim your system is functioning according to spec. And your client has a little more evidence than just your word that the system is working.
4. Versioning – Since the spreadsheets are the driving force, those are the only files that need to be checked into version control. This is nice if your client insists you use an obtrusive KM system like Sharepoint.

I’ve been using this approach for several weeks now, and have a suite of about 700 unit tests. That’s built from two spreadsheets, about 160 rows each. So far it seems to be running pretty smoothly. The difficulties lay in writing the initial script, and making sure the BA gives you a parsable Excel file (instead of a two-column, id plus semicolon delimited string format).

Who are you?

I’m a software developer, consultant, mentor, pupil, leader, son, brother, friend, Catholic, sinner, amateur poker player, Tae Kwon Do-ist (for lack of a better term), and bad writer (I’m working on that last part…)

What do you want?

I want to competently turn cash into great software. I want to recruit and organize the building blocks of a great company (the people). I want to retire with 2.5 million dollars at the age of 65. I want to be the best husband, father, brother, and son to my family. I want to finally earn a black belt in Tae Kwon Do six years after I started.

I thought this would be a good way to start out a new blog. I’m fully aware that most blogs suck, and it will be a while before this one catches any eyes. I have, however, come to realize two facts about my personal and professional lives.

One, two years of graduate school and two years of work as a contract software developer has all but destroyed my communication skills. This job just doesn’t lend itself to social growth. Without training, social and communication skills erode just like physical skills do. As an exercise, every programmer ought to try to explain the tasks for the week to a random layman at the job site; the further removed from technology the better. The division sys admin could work for a start, the lobby secretary is a better challenge. With time and practice, eventually you can try a project manager. That last one isn’t for the faint of heart.

Secondly and less melodramatically, blogs are without a doubt a powerful networking and professional development tool. We engineers wrestle with new problems each and every day, and perhaps I can contribute a thing or two to the community at large. We’re also notorious for slamming each others’ work. But I’m not one to back down from the harshness of public rebuke, so I’ll post some of the challenges I come across, and some of the solutions, and offer them up for cruel review. At worst I’ll come of as incompetent; at best I’ll find some new insight into my work.

I also want to have fun with this. So slam my attempts at comedy, too!