Selenium Issues

Question

I have been using Selenium a lot lately (testing an ExtJs app) and while in many ways it is wonderful, there are three things that cause me a lot of grief:

1. Inability to directly click on elements other than buttons. This has led me to write a bunch of Robot code to move the mouse around. That works but is a bit fragile, plus if you touch your mouse while a test is running, you are screwed. I tried the Selenium forums to see if there was a better way, and got nowhere. I think (but am not sure) that this is a fundamental limitation of Selenium's JS injection technique.

2. Inability in many cases to control what the 'id' attribute get sets to. This happens inside ExtJs and some elements let you set it, some don't, and some do but the attribute ends up where you don't expect it. You end up having to use XPath in some cases. Using XPath with ExtJs is kind of horrible as ExtJs creates massive levels of nested DIV's. You can also sometimes use CSS locators (which are also inconsistently controllable in ExtJs). (BTW, this is obviously not a Selenium problem per se).

3. The time that Selenium takes to fire up FF is too long... way longer than a normal human FF startup, about 2 seconds per test, which translates into tests that last several minutes, way too long.

I briefly looked at Watij, BadBoy and a couple of other web functional testing apps but none of them looked anywhere near as good as Selenium. (The way Selenium tests can be written in Java and run through jUnit is really, really sweet). There are also a few commercial alternatives but they are beyond my budget and there is no assurance that they would work any better anyway.

Any thoughts or suggestions appreciated.

Answer 1

I am not sure about the first two points, but as for the third, I don't think you need to start the browser for every test. You can use the Seleium server (a jar in the selenium directory somewhere) then point your tests to that e.g. localhost:6554 and that will only open the browser once.

With that you can have the steps in your script to start server -> run all test -> terminate server and you will only have one browser session across your tests.

Answer 2

My experiences (hopefully useful ;)

1. I've never had this problem, even with ExtJS. I have not used it with ExtJS 3.x, though. Is it possible that you are experiencing some thing as a result of your environment rather than Selenium?

UPDATE: As Dave Hunt reminded me, sometimes I've had to use mousedown/mouseup actions in lieu of "click"

1. I've found many clever ways to navigate using CSS locators (selenium supports most of CSS 3). In addition, you can use xpath like xpath=id('myid')//div['@class='foo'] (the ID part is crucial).

2. I've also never experienced this. Perhaps you can give some details about your environment?

Answer 3

About 3: Selenium copies at startup the firefox profile to a temporary folder. If you don't specify a custom profile, Selenium propably uses the default profile which propably is bloated with addons you don't need for the test. Startup Firefox with '-p' and create a new profile for Selenium and copy it to a location you can point selenium to. This should speed up the test a bit.

Update: Firefox Profile location / Windows: %APPDATA%\Mozilla\Firefox\Profiles

Answer 4

My thoughts:

1. There are some cases that click isn't enough, but you certainly shouldn't be limited to buttons. You might want to experiment further with your locators.

2. Why do you need to set the id attribute of elements? I have experience with testing ExtJS applications, and the problem is usually locating elements that have dynamically set ids. In my opinion this is an issue with ExtJS and not Selenium. Using smart XPath techniques using contains, starts-with, and substring can make your locators much more reliable. CSS locators are also often helpful as you mentioned.

3. As amarsuperstar says, you don't need to start Firefox before every test. If you do, you might want to consider using the browserSessionReuse command to speed up launching the browser. Alternatively you can use Selenium Grid to run tests in parallel.

Finally, it's well worth looking into the WebDriver API that will be in the soon to be released alpha of Selenium 2. In my experience Firefox launch times are reduced, and commands such as click are much improved.

Answer 5

Thanks for all the answers guys, I really appreciate it. I spent all day yesterday on this stuff and I wanted to add a couple of observations:

1. The way ExtJS lays stuff out can really make it hard to locate elements. For example, quite often the 'id' that you specified appears on an element that is 2-3-4 items in the DOM above the one you really want. The actual behaviour seems to vary greatly depending on the type of element. I have half a mind to write all this up for the benefit of future Se-ExtJs testers, as it all seems very trial-and-error and tedious. But ultimately it seems like it can be made to work nicely. And, of course, this is in no way a reflection on Se. Whether it reflects poorly on ExtJs, I'm not really sure, but it is amazing how many DIV tags even fairly simple projects create.

2. This is probably a 'well OBVIOUSLY' but to anyone else doing this, I'd recommend getting comfy with XPath. It seems a bit obtuse at first but after a few hours, as noted above, you can find almost anything with it, and almost always in ways that are not overly brittle.

Happy Holidays!

Answer 6

Selenium is one of the backends to the TestPlan testing framework and it can address a few of these issues for you.

1. We don't seem to have any problems here. Our front-end uses many different locator syntaxes to locate any elements on the screen. Though if your page is complicated and Selenium truly can't do it then ours won't help you either.

2. We base everything on XPath, so after a while you just get used to it. There are all sorts of shortcut syntax that you can use in XPath that may help. In TestPlan scripts however you can also use variable expansion in XPaths which makes them much easier to maintain.

3. TestPlan caches browser sessions when possible and not otherwise requested. This helps the speed a little bit, but only so much since normally you want a fresh session for each test anyway.

TestPlan