This sounds very promising. Thanks Jason for working so late on Friday
night, or should I say Sat morning considering your time zone :)
Have a great weekend !!
Anissa.
Ken Paulsen wrote:
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>