I’ve been using JWebUnit to put load on our sakai instance in order to work through some performance problems we’re seeing in production, but can’t seem to reproduce on dev or qa. JWebUnit has been a pleasure to work with, creating 100+ concurrent users is a snap. With code like:
tester.beginAt(”/portal”);
tester.setTextField(”eid”, userEid);
tester.setTextField(”pw”, pw);
tester.submit();
you can log a user in, and then
tester.gotoPage(”/portal/site/” + siteId);
tester.clickLinkWithText(”Resources”);
navigates the users through the portal and tools. One issue I had with JWebUnit and Sakai is the opaque names and IDs that Sakai’s portal generates for the tool iFrames. In Sakai, tester.gotoFrame(frameNameOrId) doesn’t work without a slight modification. Adding some code to this method to find the frame by its order on the page rather than its name or id, solves this problem. Calling tester.gotoFrame(”0″) put me into the first tool’s iframe, enabling navigation through tools themselves.
Although this kind of stress testing shouldn’t typically involve a Java developer, the code is easy enough to follow that reasonably tech-savvy QA staff should be able to put together new test scenarios. The only “tricky” part is the multi-threading required to generate concurrent users, but that’s sufficiently separate from the “user behavior” part of the code that it shouldn’t be a problem.