I've actually gone the other way and gone a little lower tech using
HttpClient. It appears I may have a working solution. I really don't
care if the components render or not (that's Woodstock's
responsibility), I just need to know if the page is displayed
correctly (e.g., an Exception wasn't thrown preventing the page to
complete). SInce HttpClient is closer to the bare protocol, I don't
have to worry about element IDs and handles, and can manipulate the
request/response directly. The BeforeTest logs the user on before
each test, and I have four tests, only the first of which is
implemented, and it makes sure that the frameset is rendered. The
other three tests will verify that each frame in the set successfully
renders, and I may add some more to test, for example, the web
application deployment page. We'll see.
Progress! :)
On Sep 12, 2008, at 4:37 PM, Jason Lee wrote:
> 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
>
Jason Lee - x31197
Senior Java Developer, Sun Microsystems
GlassFish Admin Console Team
Email: jasondlee_at_sun.com