Bug 744204 - Remove selenium locator hooks
Remove selenium locator hooks
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.1
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: FutureFeature
: 786217 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-07 09:24 EDT by Jay Shaughnessy
Modified: 2013-09-15 18:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-15 18:47:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Shaughnessy 2011-10-07 09:24:52 EDT
For Selenium automation we pervasively added support for Locatable widgets, basically setting explicit, hierarchical IDs on all of the widgets to be
able to perform repeatable tests.

This adds complexity to the code, as well as some overhead with a bunch 
of string generation.

We have ditched Selenium in favor of Sahi, and we are not using the 
locators.

Although folks are still trying to use Locatables, I don't think it's 
been fully maintained and I'm sure running with locators on would 
probably not work well at this point.

Although it still can be useful at times for debugging, the weight of
keeping it in is probably not worthwhile. It's not trivial, it will touch
a ton of stuff, and there are actually some built in hooks that enhance
destroy logic.  But overall I think it's a burden, and increases code
complexity, making it harder for us, and potentially contributors.
Comment 1 Mike Thompson 2012-01-31 13:34:22 EST
Additional commentary from irc with jshaughn and mtho11:

we thought we were golden given that SmartGWT provided selenium integration out of box
but things never worked well
for whatever reasons the selenium functions for determining when a widget was present/visible/enabled never seems to work quite right
and even with repeatable 'locator ids' it was still tedious to write testws
those aids all had to be assembled in the test code etc
so QA started looking for alternatives and found Sahi
which does not actually use the locators, it uses a different mechanism for identifying widgets (i guess, I'm not familiar)
I think it's positional or something like that

Anyway, now we have all of this locator id stuff in place, and a bunch of 'Locatable' subclasses for smartgwt widgets.
we also have a tone of destroy() methods implemented to avoids things like ID clashes. Meaning, proactive destruction as opposed to letting SmartGWT clean up the DOM at its leisure

it's actually the destroy() stuff that could be the delicate point

I'm not sure whether we should keep that stuff in there (and there is some support down in the Locatable subclasses) or try to take it out
it's not really, so my thought would be to leave it in
we may just have to create a couple of new Subclasses to replace the Locatables that have destroy support.
Even though the destroy calls may not be necessary, proactive cleanup may not be a bad thing
from a regression perspective I'd say leaving it as-is would be preferable
Comment 2 Mike Foley 2012-02-02 14:55:04 EST
*** Bug 786217 has been marked as a duplicate of this bug. ***
Comment 3 Mike Thompson 2013-09-15 18:47:50 EDT
Jay already removed the selenium stuff this is old and no longer relevant.

Note You need to log in before you can comment on or make changes to this bug.