A Quick Look at PesterCat

My research into UI-testing tools continues. A nice resource that has been guiding my efforts, although a bit out of date, does have a nice compilation of candidates for functional testing, load-testing, and etc.

A next candidate, PesterCat, tests at the HTTP request-response level. So it's moreless HTTPUnit with a nice GUI around it. This precludes both the "identify the element to click on" model and the "add pause here" stuff needed in both Selenium and Tellurium; imo, this is a Good Thing. The playback doesn't actually launch a browser at all, it just runs the HTTP requests (so it runs very quickly relative to the launch-a-browser approach, which is also nice) and lets you check the HTTP response for what you're looking for. Assertions can be done with Xpath, regular expressions, etc.; I've not explored that aspect fully, but was able to succeed on a simple assertion without too much trouble. So one (possibly show-stopping) downside of this is one can't test what the user-facing stuff looks like, can't test what the Javascript has done after the response is received, etc. So, perhaps not well-suited to AJAX-centric webapps.

The GUI is simple, clean and intuitive. Just like you'd expect for a $50 tool - not bogged down with too many features, so the GUI is still usable.

In theory it can be automated, since the scripts are exported to XML that can then be run from Ant scripts - but the evaluation license doesn't support saving anything so I couldn't test drive that part. The problem I see is that sending requests at the HTTP level calls for data-specific values that make tests less repeatable - e.g. instead of clicking on "My FooBar" and hitting "Delete", you might have to send a request with the ID of the object, as represented on the back end (since the ID is the unique identifying attribute, a typical setup). And, when the test is next executed, that ID could be different (especially if you're creating test data in your tests; you'd have to e.g. parse the returned HTML to figure out the ID), so you can't rely on that break of encapsulation (as usual).

PesterCat requires SSL to be turned off and must be configured as the browser proxy, but only for recording of tests, not for playback (since there's no browser needed for playback). The proxying noticeably slows things down when recording a test (that's with Firefox 2.0; this might be faster with 3.x). It is considerably easier constructing tests than with Selenium or Tellurium - since it's simply replicating HTTP requests, and you're not goofing around with HTML ID's, Xpath, pauses, etc. - but as noted, it's also more narrow in how it can be applied.

If it weren't for how slow the proxy is, this tool would actually be quite useful for monitoring HTTP requests, since you can filter out the GIF's, JS, PNG, CSS, etc. requests, all of which clutter the FireBug console pretty badly. We're also going to look into how useful PesterCat might be in fleshing out the URLs needed to construct JMeter tests, which last time I checked was one of the harder-than-I-wanted-it-to-be aspects of that load-testing tool.