I felt a bit like an extreme ironist this week as I wrote a plugin for Excel in Visual Basic, surely one of the more unit-test-unfriendly languages out there. I’ve sworn never to write code without a unit test again, but how the heck am I supposed to write test-first when the language is designed for accidental programmers who don’t know what an object is, much less a unit test?
I did find it was possible to write working unit tests for each of my non-interactive procedures once I embraced the notion of using Excel itself as the interface. The outputs go into cells and Excel formulas check whether they match the expected values. The plugin generates random strings so there’s a simple randomness check for a roughly even distribution – hardly the Diehard tests but it works.
There’s one procedure (I guess it’s called a SUB procedure in the VBA world) that I can’t test from within Excel, because it’s the one that actually opens forms and interacts with the user. If this were a commercial product, I’d use WinRunner to simulate a user clicking and typing data, or try to find an open-source alternative, but since we’re just using the plugin internally I’m happy with a manual test carefully documented in one of the Excel sheets.
I don’t think I’m going to be adopting VBA programming (or extreme ironing!) as a hobby anytime soon, but it was a fun experiment – a little like our last code dojo, where we imposed some severe restrictions to see how far we could push ourselves.