|
|
|
Re: Suitability of Jubula for web apps? [message #793553 is a reply to message #793372] |
Wed, 08 February 2012 09:29 |
Alexandra Schladebeck Messages: 1613 Registered: July 2009 |
Senior Member |
|
|
Hi,
The driver that Jubula uses to execute web tests is Selenium, so it has the same advantages and disadvantages as Selenium does. As far as my understanding goes, the driver calls the methods that would be called if clicks were performed, and performs checks to make sure that the click could have been performed in the first place. I agree that it is much preferable to send real clicks (which is why we do it for all toolkits we've written ourselves), but faced with the choice of implementing our own web toolkit (which we had done once before in the past, with the experience that the browser-specifics are a bit of a nightmare...) or using an existing mature cross-browser driver with an active community, we went for the latter.
As for W3C conformity - the likelihood that non-W3C conform AUTs can be tested is high - it's not a question of us explicitly removing support for non-conforming AUTs, but should be understood as a statement of where we see our responsibilities for increasing and improving support for web components. In any given toolkit the conformance to standards is something that makes automated testing easier and so we tend to place higher priority on bugs that hinder testing of standards-compliant AUTs.
Based on all this, I'd recommend giving Jubula a try when you get your application and see whether they are a good fit.
Hope the information helps,
Alex
|
|
|
|
|
Re: Suitability of Jubula for web apps? [message #794423 is a reply to message #794345] |
Thu, 09 February 2012 09:11 |
Alexandra Schladebeck Messages: 1613 Registered: July 2009 |
Senior Member |
|
|
Kevin - you are misunderstanding the concepts. "Real clicks" use an API to simulate actions at the OS level so that the the computer itself can't distinguish whether it came from a tool or a keyboard. That's about as close as you're going to get short of having a mechanical arm doing the entry.
A normal click by a user in a browser would go via the mouse through various layers to the webserver, resulting in a request to that webserver. Selenium fires DOM events using Javascript therefore bypassing the mouse level. So, although the computer can tell the difference, the webserver can't. It's not pretending, it's just that the click doesn't actually get performed at the OS level. Like I said, there is a gap there (like what happens if the DOM event for text entry is fired without checking whether the text field can accept text) - but it's smaller than your post makes out. There are, for example, other frameworks which bypass the browser layer (and therefore the DOM) completely.
Maybe this information helps to clarify the matter. We're happy to help if you need more information that will help your testing and understanding, and are always interested in an open discussion, but please try to avoid incendiary statements.
Best Regards,
Alex
|
|
|
|
Re: Suitability of Jubula for web apps? [message #794508 is a reply to message #794424] |
Thu, 09 February 2012 11:32 |
kevin zamora Messages: 7 Registered: February 2012 |
Junior Member |
|
|
Sorry, didn't intend to cause any incendiary thoughts - written prose and feelings are often at odds with one another. However, I was attempting to arrive at some clarity. I think some of the comments you made should be put into your documentation because, without them, I'm sure you will (or should) get questions from others as well.
I'm VERY HAPPY you clarified what is happening and now I am on a quest to see how other frameworks approach web automation testing. I wonder if Selenium itself would have been as honest and upfront as the Jubula team about their method of test? The DOM approach is an A- or "B" approach but if others are doing the same, then that is the standard. I suppose the gap could be filled by another tool (if any) to check if text could be entered at all.
Q1. Is that the only gap you are aware of? The entry of the text/click itself? left, right mouse, scrolling wheel mouse activites, etc., will be simulated via DOM events.
Q2. I understand you have a record and playback mode like Selenium (I know Selenium very little and I will be contacting them). Does the record and playback work the same way? That is, even though you record the human interaction, does it get translated to DOM events using JavaScript?
Q3. I know you probably are not supposed to answer any question like this but do you know of any tools that do enter the real keystrokes and mouse events? Maybe nobody does it?
Thanks for your answers. I think you can appreciate it is important for automation testers to know the limits of their tools, the caveats, etc.
Best regards,
Kevin
|
|
|
|
Re: Suitability of Jubula for web apps? [message #795262 is a reply to message #794609] |
Fri, 10 February 2012 09:05 |
Alexandra Schladebeck Messages: 1613 Registered: July 2009 |
Senior Member |
|
|
Hi Kevin,
Thanks for your comments and questions. Here are some answers :
1. This is the only gap we're aware of, but bear in mind that pretty much all actions can be brought back to either clicks or text entry. It's more of a conceptual gap than one affecting specific actions. I did look for documentation or discussion on the Selenium side of this, but didn't find anything. If you find some interesting links, please feel free to post them.
2. We've only implemented the record and play mode for Swing and SWT/RCP (and even there, it's in although we think you shouldn't use it - more on this in this blog entry). Selenium does have a record and play mode, but you couldn't e.g. record a test with Selenium and replay it in Jubula.
3. I would be happy to answer this question if I had an answer. I don't know of a web testing framework that does real clicks (something to do with the difficulty of finding out component positions in a browser-independent and platform independent way I believe).
4. Selenium is pretty much "just" an API. The level of abstraction and additional tooling that the Jubula ITE offers are, in our opinion, an advantage. We're aware that what we support is currently a subset of what Selenium supports, but it's a work in progress.
If you find out more information, then feel free to add it here
Best regards,
Alex
|
|
|
Re: Suitability of Jubula for web apps? [message #796917 is a reply to message #795262] |
Sun, 12 February 2012 20:26 |
kevin zamora Messages: 7 Registered: February 2012 |
Junior Member |
|
|
Hello Alex,
I played with html toolkit. After fumbling around, I need some help.
My first goal is to simply create one or more test cases that simply invoke a link on a webpage.
I got so far as to configure my AUT to correctly launch IE8 with a desired website (to test). I noticed when I did this it said "remote control" on the title bar and the website was directly underneath (IE8 was void of all the other standard navigation controls: url text box, tool bars, back, forward buttons, etc.)
I created a test case "Check URL" and then made a test suite out of it.....but it didn't object map to the html link very well (still got an error after I object mapped so it must be the wrong type of test case)....is "CHeck URL" reserved for testing the Browser itself?? That is what it looks like in the reference documentation.
So two questions:
1. What "reference" test case do I use to be able to click on a link on a webpage. Initially, I just want to know how
to do that. Afterward, I will want to do things like hover over an item, wait for a drop down, and then click one of
the drop down links.
2. Please clarify how the unbound_modules_html actions are used. If they are used to control the browser, how do you configure the AUT to start the browser so that the browser navigation controls are not hidden (like I saw with the "remote control" window).
Hope that is clear. I'm going to use one of your smiley faces
-Kevin
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05361 seconds