We did originally look at using Ruby via IronRuby but noone knew it well enough on the team so we didn’t go with that.

The other benefit of the spreadsheet is that for some of the calculations we had the formulas in the spreadsheet so it was effectively a double booking system for ensuring that we had worked them out correctly!

Thanks for sharing your practices. I’ve used Excel spreadsheets to drive tests of some complex calculations in the past, and even though it could have been considered almost as unit tests (testing one single service), they were still acceptance tests since the business analyst was able to “validate” them (still with help from developers anyway).

I was using Apache POI to read straight from .xls files. Now I’d have a look at the various BDD frameworks as well for that kind of data-driven testing.

To me, the natural approach to software development is to submit code to implacable ‘wide-and-wild’ refactorings until it matures to the point in which the ‘senses are pleased’. No progress without the protection of a reassuring safety net.

I understand acceptance checks as sanity checks concerned with the detection of large-grained deviations from the system’s intended goals (ultimately, its raison d’etre), allowing quick recalibration while things can still be undone/fixed in reasonable terms.

You say that acceptance tests are invaluable even in situations in which we are fooled to believe that ‘no harm can result from such a small change’. This is a perfect statement! I think this is one of those ‘obvious’ truths that nonetheless requires people some time and experience until it is fully appreciated.

Just wanted to add that in my view unit tests differ from acceptance tests in the way that they are indeed ‘more’ disposable in nature. They usually do not age well and, along time, tend to be discarded or commented out as a source of documentation. Their use is frequently more ad-hoc and temporary, although of course no less important.