Been using Watij at work to do load testing. I am testing Foglight 5.0. Foglight is a application monitoring tool. You install it on a computer then deploy agents to other computers. The agents collect information and send it back to Foglight. Foglight saves the data in a database. A user can then log into the web console for Foglight and view the data. A Foglight cartridge is a package of agents, configuration files and schema information. You would have an Oracle Database cartridge. This would have an agent which monitors an Oracle database, sends back all the information an Oracle Database Administrator would be interested in then displays it in a manner the DBA would appreciate. The 'cartridge' has default dashboards (a dashboard is a chart/table/view of the agent data) and rules (a rule does things like email the DBA when the database crashes, if Foglight detects a bottleneck, someone tries to illegally access the database, etc.). There are other things like reports (PDF) and analysis tools.
So, if you load all the cartridges into Foglight (OracleDB, WebLogic, WebSphere, Windows, Solaris, AIX, HP-UX, Vmware, MySQL, DB2, etc.) you will have hundreds of different views. For example, just the Windows cartridge will have agents for DiskIO, FileSystem, CPU, Memory, EventLog, AppMonitor, WebMonitor, ApacheSvr, LogMonitor, etc. and each agent will have dozens of views.
Verifying all these views can be quite time consuming. Each dashboard has an associated URL. As a user of Foglight I would log into the console (username/password) then select a dashboard from a treeview. I could also type the URL into the address bar and go to the dashboard directly.
This is how I use Watij. I created a set of jUnit test cases. The setup() was starting IE and logging into the Foglight Console. Each test case [test*()] was loading a URL, i.e. dashboard. The tearDown() was logging out of the console and quitting IE.
One of the challenges I faced with Foglight's Web Console Framework (WCF) was the use of AJAX and client-side Javascript. A fair amount of the code was in the form of Javascript on the client side. This meant, the HTTP response would complete, Watij would see the HTTP request as done but the client (Internet Explorer) would still be processing the Javascript (many of the views were complex enough that a page would take an addition 1 to 5 seconds to render).
The solution: WCF has a GIF which they set the style="VISIBILITY: visible" when the page is rendering and it gets changed to style="VISIBILITY: hidden" when the rendering completes. So I just wrote a method which gets the CSS for the image as a string then uses the match method of Java String to search for "style=\".*VISIBILITY:[\s]*visible.*" and does a loop until this changes. Basically it is a:
do {
// sleep 250 milliseconds
// get the CSS in the string s
} while(s.matches(REGEX));
The moment the style changes from visible to anything else, the loop exits and I know the page is really done. As a double check I do a windowCapture from Watij then manually inspect the images.
Darrell