Sounds good! It will be important to get at least the tree frame tested
so we can ensure AMX calls are working as expected.
Thanks for putting in the extra effort to get this working!
Ken
Jason Lee wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>