Bug 744204

Summary:	Remove selenium locator hooks
Product:	[Other] RHQ Project	Reporter:	Jay Shaughnessy <jshaughn>
Component:	Core UI	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Mike Foley <mfoley>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.1	CC:	hrupp, mfoley, mithomps
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-15 22:47:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Jay Shaughnessy 2011-10-07 13:24:52 UTC

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 18:34:22 UTC

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 19:55:04 UTC

*** Bug 786217 has been marked as a duplicate of this bug. ***

Comment 3 Mike Thompson 2013-09-15 22:47:50 UTC

Jay already removed the selenium stuff this is old and no longer relevant.