Red Hat Bugzilla – Bug 744204
Remove selenium locator hooks
Last modified: 2013-09-15 18:47:50 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
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.
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
*** Bug 786217 has been marked as a duplicate of this bug. ***
Jay already removed the selenium stuff this is old and no longer relevant.