It is easy to get back the runtime DOM, i.e, html, using jQuery. But
the
trick is how to get back the closest set of elements if none can be
found
for a locator.

In your case, it is very strange that the id cannot get back the
element. I
suggest you remove the parent container and use the element with id
directly.
Usually, the id will be unique in the DOM. But this wouldn't work if
the id
is dynamically assigned.

On Aug 14, 4:53 pm, Ben Groeneveld <[email protected]> wrote:
> Perhaps something that would help determine why in our case the
> isElementPresent() can fail.  In Firebug I can see the static  element that
> should be present.  I know the target I am searching for.  I would assume
> there is still a mismatch then in the actual search matching the two - so
> viewing the runtime DOM should be perfect.
>
> On Fri, Aug 14, 2009 at 11:51 AM, Jian Fang <[email protected]>wrote:
>
> > Anyway, I am going to add a diagnosis method to access the runtime dom for
> > the UI element or the whole UI module and also put back the logging
> > capability to the Engine so that it is easier for our users to debug/trace
> > problems. Will let you know when it is ready.
>
> > Any suggestions on what information you want to see for the new diagnosis
> > method?
>
> > Thanks,
>
> > Jian
>
> > On Fri, Aug 14, 2009 at 1:00 AM, Jian Fang <[email protected]>wrote:
>
> >> Hi, I tried to run your test, but could not go forward because I cannot
> >> pass the login piece and there are dependencies on other files.
>
> >> I looked at your code and like to share with you my observations:
>
> >> 1) Most UIs you defined are just one Container with another UI element you
> >> want to work on. This is really not a preferred way because it is similar 
> >> to
> >> work on individual UI and you cannot exploit group information inside a set
> >> of UI elements. I see you put group attribute on these Containers, which
> >> does not make sense either because you only have one UI element. Group
> >> locating is only useful when you have multiple UI elements.
>
> >> 2) As for Ajax, the really power in Tellurium is to use UI template, for
> >> example, if you have
> >> Table or List object, you can define what the UI pattern looks like. In
> >> this way, Tellurium can handle dynamic Ajax response, for example, our
> >> Tellurium issue data grid is described using a Tellurium Table object. More
> >> details of UI templates on
>
> >>http://code.google.com/p/aost/wiki/UserGuide?tm=6#UI_Templates
>
> >> 3) The dump method just shows the locator (XPath or jQuery) Tellurium
> >> generates for your
> >> UI element, it does not indicate anything if the UI element is actually in
> >> the DOM or not at runtime.
>
> >> 4) The html is very complicated and I really don't have time to go through
> >> it fully. The possible reasons that the isElementPresent method returns
> >> false for a UI element could be that the UI element is not there indeed or
> >> the generated runtime xpath is not correct. For example, you can record the
> >> xpath generated from Selenium IDE and the one generated by Tellurium. After
> >> you stop at the breakpoint, you can use DOM inspector/XPather to validate
> >> the two xpaths to see if you can find the UI element with them. If the 
> >> xpath
> >> generated by Tellurium cannot find the UI but the one from Selenium can, 
> >> you
> >> need to refactor you UI module to make it work.
>
> >> 5) Seems you use ids for UI elements a lot, are these ids dynamic or
> >> static? If they are static, you can try to use jQuery selector, which is
> >> super fast with ids. If they are dynamic, you cannot really use them
> >> directly in your UI module, but you can put the id pattern there instead 
> >> the
> >> id itself directly.
>
> >> Please post the selenium test code and the log file. I like to see the
> >> xpath generated from Selenium IDE. I would suggest you to refactor you UI
> >> modules to use Table and List objects to address the Ajax responses.
>
> >> Thanks,
>
> >> Jian
>
> >> On Wed, Aug 12, 2009 at 9:15 PM, John <[email protected]> wrote:
>
> >>> Would it be possible for you to pack your project to only include that
> >>> page's html source
> >>> and the corresponding test cases. Then send them to my email address.
> >>> I can use the MockHttpServer
> >>> to debug your code.
>
> >>> Thanks,
>
> >>> Jian
>
> >>> On Aug 12, 6:40 pm, Ben Groeneveld <[email protected]> wrote:
> >>> > We looked at this in Windows Firefox also with the same results.  In
> >>> debug
> >>> > at breakpoint after Ajax requests an examination with Firebug shows the
> >>> tag
> >>> > is there.  But the tag is not found by our DSL or TestNG codes.  We did
> >>> not
> >>> > verify this with teJQuery just Firebug.
>
> >>> > If we write a SeleneseTestcase and perform the same test -
> >>> isElementPresent
> >>> > - the id is found.  So it would seem to be some issue with Tellurium
> >>> > processing.
>
> >>> > Not sure how to proceed.  It is nice that it works in IE, but all of
> >>> our
> >>> > continuous integration is on a Redhat server.  Hope that helps, BenG.
>
> >>> > On Tue, Aug 11, 2009 at 12:10 PM, Jian Fang <[email protected]
> >>> >wrote:
>
> >>> > > If you use jQuery selector, do the similar steps, i.e., generate the
> >>> jQuery
> >>> > > selectors using dump().
> >>> > > Set the breakpoint and once the program stops at the breakpoint, open
> >>> up
> >>> > > Firebug console in that window,
> >>> > > you should be able to run jQuery in Firebug console directly since
> >>> the
> >>> > > custom selenium server comes with jQuery 1.3.2.
>
> >>> > > For example, you have generated jQuery selector "div > span", then
> >>> you can
> >>> > > run the following jQuery
> >>> > > in Firebug
>
> >>> > > teJQuery("div > span")
>
> >>> > > to see if it returns any elements. Note that we gave up the control
> >>> of $
> >>> > > and changed jQuery to teJQuery.
>
> >>> > > Thanks,
>
> >>> > > Jian
>
> >>> > > On Tue, Aug 11, 2009 at 2:23 PM, Jian Fang <[email protected]
> >>> >wrote:
>
> >>> > >> BTW, to debug, you may need to use your Firefox profile (settings in
> >>> > >> TelluriumConfig.groovy if you use the embedded selenium
> >>> > >> server) so that you have the DOM inspector/XPather plugin available
> >>> on the
> >>> > >> running Firefox instance, also you may need to turn
> >>> > >> the mutliple window flag on.
>
> >>> > >> Thanks,
>
> >>> > >> Jian
>
> >>> > >> On Tue, Aug 11, 2009 at 2:15 PM, Jian Fang <
> >>> [email protected]>wrote:
>
> >>> > >>> Would it possible that in Firefox, the UI element corresponding to
> >>> > >>> "EcisPlusUiQrInnie.expand" also
> >>> > >>> got updated after the Ajax response came back? One way to verify
> >>> this is
> >>> > >>> to use the dump() method to generate
> >>> > >>> all XPath locators for different UI objects including
> >>> > >>> "EcisPlusUiQrInnie.expand", put a breakpoint
> >>> > >>> on
>
> >>> > >>> click "EcisPlusUiQrInnie.expand"
>
> >>> > >>> and try to find if the generated XPath could be found using DOM
> >>> > >>> inspector/XPather plugin after the program
> >>> > >>> stops at the above breakpoint, i.e., after the Ajax response comes
> >>> back.
>
> >>> > >>> Let us know what you find.
>
> >>> > >>> If you use jQuery selector, it would be another story.
>
> >>> > >>> Thanks,
>
> >>> > >>> Jian
>
> >>> > >>> On Tue, Aug 11, 2009 at 1:57 PM, Ben Groeneveld <
> >>> [email protected]>wrote:
>
> >>> > >>>> Reran the script using Firefox 3.0.13 and 3.5.2 on Fedora
> >>> > >>>> 11 using your latest Tellurium TestNG reference project
> >>> tellurium-0.6.0.  On this and similar ajax segments of the script:
> >>> > >>>> times out waiting for ewlements expected to be present.  The same
> >>> script
> >>> > >>>> works well on IE7 WindowsXP same Tellurium project.  The best that
> >>> I can
> >>> > >>>> describe the behavior is "after an Ajax request subsequent
> >>> searches for
> >>> > >>>> elements already existing or newly added fail."  For example, in
> >>> the
> >>> > >>>> following dsl:
> >>> > >>>>     click "EcisPlusUiCAV.Save"            // Ajax
> >>> > >>>>     println "Testing - Pausing"
> >>> > >>>>     pause 10000
>
> >>> > >>>>     println "Testing - Verification In Quick Reference"
> >>> > >>>>     click "EcisPlusUiQrInnie.expand"            // Ajax
> >>> > >>>>     println "Testing - Pausing"
> >>> > >>>>     pause 10000
> >>> > >>>>     captureScreenshot "ExpandScreenShot.png"
> >>> > >>>>     def checkEmail = getText("EcisPlusUiQr.CustomerEmail")
>
> >>> > >>>> The .Save causes the second .expand to fail on a Selenium
> >>> > >>>> isElementPresent.  If I comment the .Save, then the .expand
> >>> succeeds, but
> >>> > >>>> then the getText fails on an isElementPresent.  Yet the screenshot
> >>> displays
> >>> > >>>> the element.  It would seem the Ajax requests are causing a side
> >>> effect, not
> >>> > >>>> just related to displaying previously non-existent content..  Hope
> >>> that
> >>> > >>>> helps, BenG.
>
> >>> > >>>> On Mon, Aug 10, 2009 at 9:04 PM, Jian Fang <
> >>> [email protected]>wrote:
>
> >>> > >>>>> I am also curious why it is not working for Firefox. If you
> >>> increase
> >>> > >>>>> the timeout threshold, the test still times out in Firefox?
>
> >>> > >>>>> The new method waitForAjaxResponse will be added once Mikhail
> >>> finishes
> >>> > >>>>> the prototyping.
>
> >>> > >>>>> Thanks,
>
> >>> > >>>>> Jian
>
> >>> > >>>>> On Mon, Aug 10, 2009 at 7:04 PM, Ben Groeneveld <
> >>> [email protected]
> >>> > >>>>> > wrote:
>
> >>> > >>>>>> Works like a charm in IE on windows.  We are curious - if you
> >>> are
> >>> > >>>>>> using Selenium underneath then why is it not working properly on
> >>> Firefox?
> >>> > >>>>>> Is this a Selenium restriction or . . .  Development on unix
> >>> would be
> >>> > >>>>>> preferable.  When do you anticipate availability in Firefox?
> >>>  Thanks, BenG.
>
> >>> > >>>>>> On Mon, Aug 10, 2009 at 11:01 AM, Ben Groeneveld <
> >>> > >>>>>> [email protected]> wrote:
>
> >>> > >>>>>>> That might be the issue - I am using Firefox on Fedora linux.
> >>>  I'll
> >>> > >>>>>>> try it on Windows.
>
> >>> > >>>>>>> On Mon, Aug 10, 2009 at 9:28 AM, Jian Fang <
> >>> [email protected]
> >>> > >>>>>>> > wrote:
>
> >>> > >>>>>>>> waitForElementPresent is still a selenium call under the hood.
> >>> Have
> >>> > >>>>>>>> you seen the page updated before
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"tellurium-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/tellurium-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to