*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).