Hi everyone, I feel like an oaf, it is only now that I realized that I replied to Vihang's post by replying directly to his address instead of replying to the mailing list. I have reproduced our exchange after this message, but you don't have to read that to understand the questions I am asking now:
Having run the tests, I can confirm that ClickElement on the element's XPath did not trigger the loading of a new page (however the application otherwise works). Previous investigations while trying to test with another testing tool (Selenium) showed that it was due to SmartClient's design: * Mechanic (as far as I understand it from the HTML structure, inspected with Firebug): When you click on a button, the "click()" event is not triggered by the HTML event you just clicked on, but by another object that is registered in the HTML element as an "eventproxy" attribute. And using Firebug's console to type "foo.click();" does the same thing as clicking the button <div eventproxy="foo"> manually. However, using either Webtest's ClickElement or Selenium's click on it (or on any of its children) does not work. * Explanation from Isomorphic, SmartClient forums administrator (http://forums.smartclient.com/showthread.php?t=2312): ""click" is not reliably fired by browsers when content is changed during the mouseDown/mouseUp events, so SmartClient components react instead to a mouseDown/mouseUp sequence." However, even if clickElement worked, that would not be enough, because, in Smartclient apps, "DOM structures vary by browser, skin, and version of SmartClient." Which means that, even if clickElement worked, the resulting tests would be quite brittle. The methods called on the "eventproxy" object, however, are quite stable and guaranteed to work, whatever browser, skin or version of SmartClient. Which leads me to the following track: I would like to program a custom step for webtest, that would look like: <smartclick smartid="foo"/> And that custom task would simply execute, in the browser's context, "foo.click()". What do you think? Is it possible? Are there other, simpler options? Do you have any recommendations in defining such a new step? Thank you in advance, Jean Hominal. Here is, for the record, a copy of my previous exchanges with Vihang (sorry for bothering you): So, here is copy of my reply to him: > Thank you for your reply Vihang. > > After having seen your reply, I have begun to think of another approach... > would it be possible to define a new step, so that I could write: > <SmartClientClick SmartID="foo"/> (in ant-xml) > or > SmartClientClick(SmartID:"foo"); (in groovy) > > This step would run the aforementioned bit of Javascript in the Browser's > context, "foo.click();" > > If that is possible, how should I begin? How can I make sure that this task > will be ran correctly? > I guess I would have to extend the Step class, but I am not too sure about > what I would have to do so that my webtest would recognize that step. > > Thank you in advance for your help. Here is a copy of Vihang's last reply: > Hi Jean, > > Webtest is an ant build and they have their source available on the main > website. You can download the code and change any of the steps provided in > their index. > > However, I would not recommend this because the source is rather large and > understanding is will take some time. > > Have your tried simply doing the clickbutton step? Have you tried creating a > project and running it? I think if you define is as an input on your webpage; > web-test's browser will be able to find it as an click even it. > > WebTest also have the step for clickElement. This step will allow you to > click on any element whether its an input or not. You can provide an xpath to > it or htmlId for it. > > This will click on your button. > > clickButton htmlid:"imgsubmit" > clickElement xpath: > "/html/body/span/div/table/thead/tr/td/table/tbody/tr/td[2]/span[4]/img" > > > I am sure you already know this however, think of WebTest as a web browser > that allows for clicking, verifying text, and other user interface things. It > really is an > extranal object that is interinating with the webpage as an > browser. > > It really can not inject too much of java script into the page. It can a > little bit but thats should be your last approch. Just like FireFox cant > really add code to live page while the user is viewing it. > > WebTest is made to emulate users clicking and verifying and testing webpages. > > > Please let me know if you need anything else. > > thanks, I have sent yet another reply to Vihang before writing this message, but that last reply was focused on another problem altogether (waiting for the webapplication's asynchronous responses rather than continuing the test after having simply received the HTML response), and since then, I was able to solve that problem (by using ant's <sleep/> task), so I don't feel it is necessary to reproduce that. -- Jean Hominal _______________________________________________ WebTest mailing list [email protected] http://lists.canoo.com/mailman/listinfo/webtest
