AW: [rap-dev] RAP UI Testing (automation)

["Frank Appel" <fappel@xxxxxxxxxxxxxx>]

Hi,

after all what I have seen yet and after some short discussions with Rüdiger, I think that there is a way by using PhaseListeners and adapters to add human readable IDs to the RWT widgets without changing the codebase of RAP at all. This could also be used by application developers to add speaking names to their widgets via adapters without breaking existing API methods. But unfortunately I have no time before the 1.0 release to think this over thoroughly. I will come back to this discussion after the release.

Ciao
Frank 

-----Ursprüngliche Nachricht-----
Von: rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] Im Auftrag von just4lists@xxxxxxxxxxxxxx
Gesendet: Mittwoch, 3. Oktober 2007 02:38
An: RAP project development-related communication
Betreff: Re: [rap-dev] RAP UI Testing (automation)

Hi Benjamin,

See my comments inline.
Best regards,

Joel Oliveira

On Tue, 02 Oct 2007 19:09:15 +0200, "Benjamin Muskalla"
<bmuskalla@xxxxxxxxxxxxxx> said:
> Hi Joel,
> 
> you're right - we are under heavy work.

If you need some help on this, just let me know about it.

> To your patch: there are some problems which keeps us off to apply 
> that
> patch:
> 1) Java 1.5 requierement (no problem, one-liner)

Ok. I will fix this. It should be 1.4 correct?

> 2) 29 test cases red (did you ever run the tests?)

I believe that are red because they need to be updated and not because of broken functionality related with the patch. But I can (should) also work on this and submit the updated tests.

> These two problem could be fixed easily but there are other things to
> mention:
> 
> 3) Way more bandwidth with every ajax request and I don't see a reason

It's true. Instead of w1, w2, w3, w4,... we would get something like shell, toolbar1, button1, button2,... (twice, because for compatibility reasons, my patch assigns this generated id to both id and name attributes). I also propose to change from w1 to shell the id of the root component.
To reduce bandwidth, if possible and if this is really an issue, we could use just the first letter of the widget name... (s1, t1, b1, b2 - it's not so readable but it keeps request size).

> now to have another system property for something which really should 
> be done in another way

I tried to implement a non-intrusive patch (that, as I said, it's not an ideal solution) that allows GUI testing with tools that don't support
xpath:
- using id and name (standard html attributes) that I believe should be used for this;
- keeping the same API (without forcing developers to assign id to the widgets... should we allow developer to define ids/names for the widgets?
This could easily break the generated code...).

> 4) With the patch you just change the incremental id to an 
> widget-type-only incremental id. So far this is way better than using 
> the incremental ids for testing but it is not sufficient for real 
> tests as they would also break when you just add a new button which is 
> rendered before the to be tested widget.

True.

> Changes in this area should be done as a proper solution and not by 
> trying to make it just a little better. A proper solution could be 
> developed that way but not a week before the 1.0 release. I don't see 
> a chance to accept this patch as there are just too many problems with 
> it and no real improvement.

Again, I just tried to make version 1.0 UI test enable. This feature is mandatory for my current project (request by the validation team) and I saw some more users asking for it in the newsgroup.

> Sorry if it sounds bad but it's just to late in the cycle to address 
> these things properly.
> After the release I would be happy to talk to you about testing RAP 
> applications and how we could develop a nice solution to this problem.

No problem. I'm willing to contribute to a better solution. _:)

> One idea was the usage of XPath-like syntax to address the widgets 
> (see testing wiki page). If you have another idea, don't hesitate to 
> talk about them.

See my previous comment. I'm not relying in the xpath feature to allow tests as almost all test solutions are able to identify html "widgets"
by id/name but not all of them are able to execute xpath queries. This means that I'm targeting testing tools that allow non-java users to record a session of interactions with the application (html inside the
browser) and not ui testing based on junit or anything similar.
This could possible explain our 2 different visions.

> Just my 2 cents
>   Benny
> 
> just4lists@xxxxxxxxxxxxxx wrote:
> > I understand that everyone is under heavy work because of the 
> > release 1.0 but do you think it would be possible to merge my patch 
> > before the official release or is it already freezed?
> >
> > Best regards,
> >
> > Joel Oliveira
> >   
> 
> _______________________________________________
> rap-dev mailing list
> rap-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rap-dev
-- 
  
  just4lists@xxxxxxxxxxxxxx

--
http://www.fastmail.fm - A fast, anti-spam email service.

_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev