Tellurium having trouble finding element by ID

3 views
Skip to first unread message

Matt

unread,
Jan 5, 2011, 2:55:31 PM1/5/11
to tellurium-users
Hello,

I've been having a lot of success with Tellurium, but I've stumbled
across an input field that I can't seem to get my tests to recognize.
I was wondering if anyone might have an idea for properly locating the
field?

The facts are these:
* I'm targeting the input field using it's ID attribute, which is
unique (this was the first thing I checked...).
* The input field is initially hidden, and displayed with JavaScript
(Prototype framework) once other portions of the form are filled out.
* "isElementPresent" returns false before and after the input field is
made visible. Every other input field on the page returns "true" when
tested.
* This one input field has an event listener (Prototype "Event")
attached to it, which changes the input field's class when it receives
focus/blur events (why didn't they use CSS onfocus/onblur like they
did on every other input field on the page? No clue...).

I was wondering if the event listener is somehow keeping Tellurium
from finding the input field? Or if something else could be getting in
the way? Any suggestions on where to look for a solution/get a clearer
idea of what's going wrong would be greatly appreciated!

I'd love to provide more details, but I'm limited in what I can say
(company policy and all that jazz...).

Thanks for the help!
- Matt

Jian Fang

unread,
Jan 5, 2011, 3:49:38 PM1/5/11
to telluri...@googlegroups.com
Hi Matt,

Are you using Tellurium Core to generate runtime locators or using Tellurium new engine
for group locating?

Since the input field is hidden initially, Tellurium new Engine may have problem to locate
it. You could set the "cacheable" attribute of the Input field to be false to see if you can
workaround this problem.

If it is the former case, please post the error stack here.

Thanks,

Jian


--
You received this message because you are subscribed to the Google Groups "tellurium-users" group.
To post to this group, send email to telluri...@googlegroups.com.
To unsubscribe from this group, send email to tellurium-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tellurium-users?hl=en.


Matt

unread,
Jan 5, 2011, 7:24:04 PM1/5/11
to tellurium-users
Setting cacheable="false" didn't make a difference, though I don't
know whether I'm using Tellurium Core or Tellurium New Engine. Do you
know where I could find that information?

I've also tried defining a new UI module just for that input box,
making sure to "defineUi" after the element was visible on the page,
with no luck.

Lastly, here's a stack trace from trying to type to my mystery
element, and the locator I'm using:

InputBox(uid: "inputField", cacheable: "false", clocator:
[id:"unique_id"])

com.thoughtworks.selenium.SeleniumException: ERROR: Element
uimcal={"rid":"page.inputField","locator":"jquery=#unique_id"} not
found
at
com.thoughtworks.selenium.HttpCommandProcessor.throwAssertionFailureExceptionOrError(HttpCommandProcessor.java:
97)
at
com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:
91)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite
$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:
229)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:
52)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:
128)
at
org.telluriumsource.component.connector.CustomSelenium.getBundleResponse(CustomSelenium.groovy:
257)
at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:
88)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
.... and lots more, but this seemed like the important bit.


Thanks for the help, btw!


On Jan 5, 12:49 pm, Jian Fang <john.jian.f...@gmail.com> wrote:
> Hi Matt,
>
> Are you using Tellurium Core to generate runtime locators or using Tellurium
> new engine
> for group locating?
>
> Since the input field is hidden initially, Tellurium new Engine may have
> problem to locate
> it. You could set the "cacheable" attribute of the Input field to be false
> to see if you can
> workaround this problem.
>
> If it is the former case, please post the error stack here.
>
> Thanks,
>
> Jian
>
> > tellurium-use...@googlegroups.com<tellurium-users%2Bunsu...@googlegroups.com>
> > .

Jian Fang

unread,
Jan 5, 2011, 8:15:37 PM1/5/11
to telluri...@googlegroups.com
If you did not call useTelluriumEngine(true) explicitly, Tellurium will work in the first mode, i.e.,
Tellurium core generates runtime locators and then call Selenium APIs.

It is really wired that Tellurium cannot find the element with the id attribute. Could you debug your
test and put a breakpoint at the code where the input field becomes visible? After the test stops
there, you can use DOM Inspector or the following way to check if the input field is indeed there
at that time. Sometimes, Javascript framework likes to change the runtime id.

http://code.google.com/p/aost/wiki/TelluriumJQueryFirebug

Or you could try out Tellurium 0.8.0 snapshot, which at least dump out the JavaScript error stack
for you.

Thanks,

Jian

To unsubscribe from this group, send email to tellurium-use...@googlegroups.com.

Jian Fang

unread,
Jan 5, 2011, 8:18:16 PM1/5/11
to telluri...@googlegroups.com
Or you could call the diagnose(uid) method to see if there are any closest matches there. More details here:

http://code.google.com/p/aost/wiki/PracticalUseOfDiagnose
Reply all
Reply to author
Forward
0 new messages