I am currently working on expanding the QL tests for the admin
console. The current test just makes sure the app actually deploys,
which is helpful to a point, but we obviously need to go further. My
plan was to do this:
* Access the root context, and check for either the login screen or
the main admin page (with the frames)
* If neither is found (see below), wait a few seconds to allow the app
to deploy (in case it's the first request), then try again, failing
after x tries.
* If the unit testing framework (such as HtmlUnit) is capable of
executing JS to allow for auto login, then look for the main page. If
not, look for the login button, then "click" it
* Once the main page has been returned, examine the three frames to
make sure their contents have been rendered correctly.
While I'm certainly open to suggestions on my strategy, what I'm
having trouble with is technique. It's my understanding that HtmlUnit
is supposed to be pretty good at executing Javascript, and since I'm
going to need something a bit more sophisticated than URLConnections
(e.g., for cookie handling to maintain my authenticated state), that's
what I choose. I wasn't seeing the auto login happening, so I tried
to fall back to manual form entry and submission
(userName.setValueAttribute("anonymous"); loginButton.click()), but
that is failing as well.
Here's my theory as to why: Woodstock makes *heavy* use of
Javascript. It doesn't seem to output HTML, but, rather, a copious
amount of JS, which then handles the rendering of the component on the
client-side via DOM manipulation. My guess is that either a) HtmlUnit
is having trouble executing the JS to create the DOM elements, or b)
it is executing the JS but the in-memory DOM tree it holds
representing the page is not being updated. I'm open to other
suggestions as well, but, regardless of the cause, when I call
page.getHtmlElementById("loginButton"), HtmlUnit is throwing
ElementNotFoundException.
As far as I know, and here's where you all come in, HtmlUnit is my
best bet for this type of headless, JUnit-style testing. That leaves
me with a more "black box" testing framework like Selenium. My issue
with that is that it requires a browser and, therefore, a GUI, which
may not be available on our Hudson QL machine. There are instructions
for running Selenium in a headless environment (
http://mojo.codehaus.org/selenium-maven-plugin/examples/headless-with-xvfb.html
), but requires a framebuffer, which also may not be available on that
machine.
Having said all of that, what options do we have here? Is my analysis
of the HtmlUnit interaction correct? Is there a better alternative in
that space? Is Selenium (or something like it) our only choice? Is
that even an option given our use of CI?
I could use a push here, as I've hit a wall. Never say die, though,
right?
Jason Lee - x31197
Senior Java Developer, Sun Microsystems
GlassFish Admin Console Team
Email: jasondlee_at_sun.com