Home » Archived » Jubula » Example tests failure, and general questions about single sourcing(I tried to run the tests, and it failed.)
Example tests failure, and general questions about single sourcing [message #1007510] |
Wed, 06 February 2013 09:04 |
Gábor Lipták Messages: 21 Registered: July 2009 |
Junior Member |
|
|
Hi,
I am new to Jubula. The version, which I am using is 1.3.0. OS is Windows 7 64 bit.
My aim: we develop a single sourced client application with using Eclipse RAP and RCP. We are looking for a test tool, with which we could write the test once, and run it against both client type. As far as I understand, till I stick to the unbound_modules_concrete, I could create a test, which I could run against RAP with using HTML AUT connector, and RCP with using RCP connector. Is it correct? Are there any example projects, customers of Bredex, which are using RCP+RCP AUT and RAP+HTML AUT successfully?
At Jubula home page it can be read at http://www.eclipse.org/proposals/jubula/, that Testing RAP is currently under evaluation. Can we know something more about the schedule of RAP support development?
As I see, the "Adder" example, which is coming with the Jubula download package is something similar. There is a functionality implemented using more technologies (SWT, Swing and HTML), and Jubula can test all of them with the same test project.
The HTML variant worked. With the SWT variant I become an error, that the point to click is outside of screen bounds. What do I do wrong?
As far as I understand, one project can have multiple AUTs. I would suppose, that it is possible to create object mapping for each of them? Is it true? Can I run the same project on different AUTs with different types?
Thanks in advance,
Gábor
|
|
| | | |
Re: Example tests failure, and general questions about single sourcing [message #1007748 is a reply to message #1007732] |
Thu, 07 February 2013 12:02 |
Gábor Lipták Messages: 21 Registered: July 2009 |
Junior Member |
|
|
Hi Alex,
Thanks for the information.
As for the failing examples I also have found this thread. I guess to avoid such problems in the future, it would be a nice idea to change the actual AUT config of the Samples Project in the upcoming Jubula release to have "CENTER" type activation.
Cooperation with my company: I would be glad to work on some Jubula tasks I suggest it to my managers, since I am a software engineer. I cannot decide such things.
RAP and/or HTML testing: I have some general ideas here. As far as I see after reading the click related threads, it is also possible today to build up tests for RAP using the concrete toolkit. The biggest problem here is object mapping as I see. It is simply not flexible enough to have an identification of a component like: /div[3]/div[2]/div[4]. If someone adds something, the whole test is ruined.
One solution: could be to give the possibility to edit the object mapping manually. So I could specify some XPath expression (I guess the underlaying Selenium supports finding components based on XPath. See hXXp://wiki.openqa.org/display/SEL/Help+With+XPath. Correct the link. I could not post it). Highlighting could work as well I think. This way I could find components more dinamically, and I could check my xpath with highlighting.
Second solution: I have read in the manual, that it is possible to say to jubula, that it should take a specific HTML attribute as ID. See 4.4.2 Design for testability in HTML AUT's for details. In RAP there is no such ID. But. The javascript code generation and HTML attributes are driven by the implementations of org.eclipse.rwt.lifecycle.ILifeCycleAdapter interface in RAP. According to the custom RWT component development guide the name of this class is resolved in two possible way:
Quote:To participate in the life cycle - what is what we want to do with our custom widget - we need to provide a Life Cycle Adapter (LCA). There are two ways to connect the LCA with our widget. On the one hand side we can return it directly when someone asks our widget with getAdapter to provide an LCA. This can be done by implementing the getAdapter method in our own widget like this:
...
public Object getAdapter( Class adapter ) {
Object result;
if( adapter == ILifeCycleAdapter.class ) {
result = new MyCustomWidgetLCA(); // extends AbstractWidgetLCA
} else {
result = super.getAdapter( adapter );
}
return result;
}
...
The preferred way is to let RAP do this itself by creating the LCA class in a package called <widgetpackage>.internal.<widgetname>kit.<widgetname>LCA. The order of the internal does not play the big role. The important thing is to have internal in the package name, the package with the LCA is called <widgetname>kit and the LCA itself is called <widgetname>LCA.
Here a little example:
If our widget is named org.eclipse.rap.gmaps.GMap,
then our LCA should be named org.eclipse.rap.internal.gmaps.gmapkit.GMapLCA.
The LCA class itself must have org.eclipse.rwt.lifecycle.AbstractWidgetLCA as the super class and implement its abstract methods.
I proofed this documentation part. There is org.eclipse.swt.internal.widgets.menuitemkit.MenuItemLCA which is the adapter of org.eclipse.swt.widgets.MenuItem.
So to implement support for RAP, or to improve the support of RAP of the HTML module we could implement some Aspect (with aspectj for example), which would weave all default ILifeCycleAdapter implementations. I think with having then the JSWriter then (see for example org.eclipse.swt.internal.widgets.menuitemkit.BarMenuItemLCA) we could add a "path" of the widget, or some generated id, which contains label information, or even such informations like count of items in a table, and so on. Maybe with such extra information the whole functionality of the RCP module could be covered. The weaving could be disabled for production systems to avoid overhead or side effects.
What is your opinion Alex?
Regards,
Gábor Lipták
|
|
| | | | | |
Goto Forum:
Current Time: Thu Oct 03 20:25:00 GMT 2024
Powered by FUDForum. Page generated in 0.12684 seconds
|