[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
Its 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
its 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. Im 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 Im 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.
