Webapp testing…

December 13, 2007

…is a spectacularly boring pursuit. Extraordinarily, magnificently, dull.

I hate it.

If you’ve done much, I wouldn’t be surprised to hear that you hate it too.

Which is why I don’t do very much of it any more. What’s more, I suggest that you join me in my noble quest.

Recently, I have been letting Watij do it for me. Before I go any further, I’m not normally what one would call a fanboi. I’ve sometimes heard my own brand of rampant unchecked cynicism referred to as “cautious optimism”, but that’s about as close as it gets.

In short, Watij is absolutely great. It’s an open source lump of Java that will test your webapp—albeit currently only in IE—straight from a JUnit instance. Nothing special there, then, you might think. The fab thing, however, is because it’s just a bit of bog-standard Java code, you can start doing really cool things with it.

It’s probably useful at this point to run through what I’ve been occupying the time between train journeys with recently, and how much Watij has helped me in this task. In order to get adequate functionality to become compliant with a big European directive, a sizable chunk of the intranet workflow application on which I work has recently been changed. The terribly fin-du-siecle static JSPs have been ripped out, and replaced with lovely bright, shiny, new AJAX counterparts.

The first thing I have to do on Workflow 1 is to ensure that for a given set of input criteria, the necessary pages are displayed in the necessary order, contain the necessary questions, and provide the correct result given the answers to the set of questions asked. The spec for this workflow is a series of Excel spreadsheets. With a bit of vlookup wizardry, it’s possible to generate all necessary test cases directly within Excel [I know. Sorry.] from the spec. Given a suitably-cunning test constructor, all possible circumstances in this instance can be catered for in one class, resulting in Watij testing every conceivable route through the workflow, at each stage asserting that the right pages are shown in the right order, and contain the right questions and notifications. Lovely stuff. One click, and that’s one morning saved per release cycle. And the really groovy thing is that because the test cases were generated directly from the spec, I know the tests are right.

Workflow 2 is a complete hog. With nearly 450 separate routes through it with any one of six distinct results, editable in two unique scenarios, there’s just shy of 900 test cases to run; each of which has to be perfect. If you think for one second that I’m going through that manually, you’re having a laugh. Luckily, Watij can ride into town, jump off its horse, and—at the last minute, of course—untie me from the railway line of tedium. With details of each test case handily knocking around in Excel, it’s a breeze to generate the code necessary for the test cases from a spreadsheet. [yes—I know. I’ve already apologised] With the 900 test cases falling into 7 different categories, all I need to do is to write 7 subtly different test classes, show each of them the necessary set of cases, and voila! For the price of my computer whirring away for a few hours, I’ve just saved a few days of mind-numbing testing.

The really handy stuff comes when you use Watij in conjunction with a bit of JDBC. The application on which I work accesses its own database via Hibernate, also setting up data in someone else’s database using a bunch of RMI calls. Without wanting to sound overly technical, as far as I’m concerned, both Hibernate and RMI are just black boxes. I know my application tosses objects at them, they do something to it, and some datum gets written somewhere. As a consequence of the directive for which we’re releasing the new version of the code, the data setup scenarios are somewhat arcane. If Result X is reached, data is to be written to Tables 1, 2, and 3, except in the case where Result Y is also true, in which case some data gets written to Table 1, another bit to Table 2, and under no circumstances to Table 3. Except if it’s a tuesday. There are 31 separate routes through the data setup workflow, which needs to be tested—again—in two separate scenarios. Testing all 62 routes through this setup manually would again take at least a day, and be prone to the errors I start introducing by testing whilst unconscious.

With the setup table defined in an Excel spreadsheet, I can use that to generate the test cases [right—I’m not apologising for this any more], and use them all in the same test class. Because the test is written in bog-standard Java, once a test has been run through the GUI, I can let the JDBC do its work, going off to each table and asserting that data which should exist does exist, that when data exists it is correct, and that data which should by no means exist does not exist. Again, one mouse click, a bit of a wait, and IntelliJ shows me the green bar of success or the red bar of failure. Because the code was generated directly from the spec, I know that the tests are correct, and therefore if the red bar of failure appears, we’ve got a functionality bug somewhere, either at our side in how we construct the objects to throw at the other system’s RMI server, or they’ve got an error in how they interpret the method we’ve called. It’s brilliant!

My only slight gripe is that out-of-the-box, Watij doesn’t play terribly well with AJAX, but with a few judiciously-used wait functions, there’s nothing in there that would stop me from using it.

I know I’ve been prattling on now for a while, but I hope that I’m starting to convey how much time and precious, scarce sanity the use of Watij has saved me. It’s fab, and if anyone wants the 5-minute intro course, you know how to get in touch.