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 On Wed, Jan 5, 2011 at 7:24 PM, Matt <[email protected]> wrote: > 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 <[email protected]> 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 > > > > On Wed, Jan 5, 2011 at 2:55 PM, Matt <[email protected]> wrote: > > > 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 > > > > > -- > > > 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]<tellurium-users%[email protected]> > <tellurium-users%[email protected]<tellurium-users%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/tellurium-users?hl=en. > > -- > 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]<tellurium-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/tellurium-users?hl=en. > > -- 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.
