Re: [jubula-dev] RAP vs HTML toolkit component matching

[Zeb Ford-Reitz <Zeb.Ford-Reitz@xxxxxxxxx>]

Hi Gábor,

XPath matching does indeed sound cool (as does the idea of pluggable component recognition strategies), but as you mentioned it doesn't really match Jubula's "no programming necessary" philosophy. I would prefer an implementation that identifies the types of the HTML elements (i.e. Composite, Button, Text, Tree, etc) and assigns a generated ID based on that if no sensible ID is already defined. This more closely matches the implementation for other Toolkits (Swing, SWT). The issue then becomes figuring out types, which should be possible using an accessibility specification like ARIA.

Beyond component recognition, I believe you run into several other problems with testing RAP (and web toolkits in general, I'm sure). One example is scrolling in lists / tables / trees. IIRC, only the elements currently in view are actually in the HTML body. The rest are in a corresponding JS object that is then queried as other elements are scrolled into view in order to replace the values in the elements in the HTML body. This was one of the stumbling blocks that I encountered before running out of time on the RAP support prototype. It's far from insurmountable, but it's also not trivial.

Component recognition plus the other assorted hurdles make support for testing RAP applications a rather large task. I saw in the linked forum post that you wanted to check whether you would have the time/resources to collaborate on RAP support. Is that something that would still be possible?

 - Zeb

On 13.02.2013 17:28, Gábor Lipták wrote:

Hi,

I am the part of a team, which develops a single sourced RAP-RCP client application. We would like to use Jubula to create automatized tests, which would fit both client type. As far as I know if I stick to the lower level concrete toolkit, and I can make it working with our RAP client, I can test both clients with it. It would worth for us to put a bit more effort in RCP test design with using lower level building blocks, to get RAP compatibility on the other side.

In this thread (http://www.eclipse.org/forums/index.php/t/452654/) I had a discussion with Alex, and she suggested to ask you about my technical problems.

So currently my problem is the way, how Jubula identifies HTML (or RCP) components. In RAP there is the possibility to define CUSTOM_WIDGET_ID with the Widget.setData(String key, Object value) method, and this id will be generated into the HTML code. 

How it works:

- When I set this id for a text input unfortunately the result in HTML is a bit different than expected. There is a DIV, which contains my input element, and this DIV will have the ID, which I have defined.

- If I do not define such id, then all widgets without defined id will become a sequence number, which is variing with each run. It looks like wXXX where XXX is the sequence number

- if I define the same CUSTOM_WIDGET_ID for more than one Widget, then the RAP _javascript_ side gets crazy. It is suprising, since if the testing mode is not enabled, it is working without ID attributes without problem, however in testing mode it uses it for something.

If I want to use Jubula as it is now, I am facing with the problem, that all components in the widget tree has to have some fixed ID, which is not variing, but unique. So for example this would be a textfield in Jubula ideally:

-ShellID

--CompositeID1

---CompositeID2

----MyTextField

-----input[0]

Generating such ID (unique, reproducable, meaningful) for the noname composites, which does not have any label, is hard, or nearly impossible. If I would give an ID just for the textfield, I would have something like this for the same textfield:

-w13

--w23

---w24

----MyTextField

-----input[0]

So from my viewpoint it would be great to have some feature in Jubula, which would let me edit or define the object mapping technical element. As far as I know it is possible to match HTML elements in Selenium using XPath.  If I could define in my test a technical element like //div[id='MyTextField']/input[0], I could avoid defining every single ID in the tree, and I could provide the needed flexibility to find the input inside the marked DIV, which has my ID.

As for RCP, you could have the same flexibility. If you would take for example the Shell object, and use it as the context bean of a JXPath evaluator, it would be relatively easy to have the same XPath based matching there as well.

With XPath matching it would be also possible to match or assert elements in insanely flexible way. Like I want to match the textfield, which is red. It sounds cool, does not it? I know that Jubula is not intended to be a test tool, which is designed for freak developers using xpath, but it would be still extremely powerful to have such a feature.

I would be generally interested in your opinion about this, and I would welcome any information about extension points in Jubula, which could be used to implement this behavior.

Regards,

Gábor Lipták

_______________________________________________
jubula-dev mailing list
jubula-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jubula-dev

-- 
BREDEX GmbH
Mauernstr. 33
38100 Braunschweig

Tel.: +49-531-24330-0
Fax:  +49-531-24330-99
http: www.bredex.de

Geschäftsführer: Achim Lörke, Ulrich Obst, Andreas Vogel
Amtsgericht Braunschweig HRB 2450

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature