Five common Selenium challenges and how to overcome them

I remember being first introduced Selenium back in 2010 with the release of Selenium version 2. And like many people I’m sure, the ability to control a web browser with code written in a NotePad document was a game-changer.

Although the features in Selenium 2 were not drastically different from what is in Selenium 3 for example. There were many bugs which hampered the effort of introducing automation. And with the release of later versions (and with Selenium 4 on the horizon). Even though many have now been fixed, there are some very common pitfalls that if you’re not aware of. Can have you pulling your hair out, cause confusion and frustration trying to determine what is going on.

Tests running ahead of the browser

This situation is common and is caused by the WebDriver sending commands to the browser which it can not execute in time for in for it to execute the next one (due to network issues, slow loading elements etc). Which ultimately leads to test failure with the familiar:

selenium.common.exceptions.NoSuchElementException: Message: Unable to locate element

In this situation. Whenever you are moving from one page to another. Waiting for one page to load, or performing an action on a page which depends on another page element. I always make use of wait and expected conditions of the slowest loading page element before continuing.

There are a few wait strategies which you can make use of. Namely Implicit and Explicit being the key types (you should never use Thread.sleep() if possible). But whatever you choose. Remember to never make use of another kind of wait, as this will lead to additional errors occurring.

Personally. I use explicit waits and would advise their use to anyone. But I think it’s important that you take the time to read up on both and know their unique pros/cons before you decide which to implement for your situation.

Flaky Tests

We can define flaky tests as anything that passed previously. But now, with no modification to the code, the tests are now failing for reasons hard to define.

Not only can this problem waste time and money for testers who need to investigate the cause of the error. But it is also frustrating having to deal with test cases that keep switching from passing, to failing, for no apparent reason.

The reasons for flaky tests are many from improper location strategy, timing issues, environment changes. Or a test being tightly coupled with an outside element such as a database or third-party tool.

Two ways that I advocate to correct flaky tests are to first to document flakiness when you encounter it. You can’t fix what you aren’t aware of.

The second is to make use of a framework for your automation solution. Rather than your test suite being compromised of individual scripts and devoid of any structure.

If you are looking for an open source solution, then I recommend Robot Framework.

Pop-up Windows

Writing test cases for a webpage which has pop-up windows can be annoying. Especially if you are trying to send click commands, getText operations or navigation options to the browser and none of your manipulation methods are being registered.

The reason for this is that once a pop-up has occurred in the browser. It is now sitting in front of the window object. As is in effect it is a new entity that needs to be dealt with.

This is fairly easy though with the driver.switch.To()command.

Then by importing the Alert() module. You can send it commands such as Alert.dismiss(), Alert.accept(), Alert.getText(), Alert.sendKeys().

Not using the latest version of the driver for a particular browser

The ability of web driver to interact with your browser depends on you having the associated driver for your browser linked in your code. An example of this would be:

System.setProperty(“webdriver.chrome.driver”, “/path/to/binary/chromedriver”);

While this may seem like not an enormous problem initially. If you have multiple browsers that you need to run your tests on then this can quickly add up to a lot more code. Not to mention time wasted in checking that you have the right version of the driver for your particular browser.

This is where tools like WebdriverManager have saved me in the past and not only has it taken away that manual effort of checking each version. But also it makes my code much easier to read and nullifies the need to link to the binary within in my code.

Similar packages are available for various bindings such as C# and Python.

Incorrect location strategy

The location methods for Selenium elements are:

• ID
• Classname
• Name
• XPath
• CSS Selector
• Tag Name
• Tag Text
• Partial Tag Text

And while it may be attractive to use one over the other because it makes sense to locate elements that way. If the application or webpage is under heavy development. Take into consideration that elements may get renamed, or removed entirely.

So, for example, if you use an absolute XPath to find your element:

HTML/head/body/table/tr/td

If a new table row gets added, for example. Or the developer decides to do away with the table entirely. Your locator will not work, and you’ll face a failing test.

Now I like using XPath locators where possible. But always construct your own to ensure maximum flexibility. Rather than relying on Google Dev Tools to create one for you.

To help with that, I recommend using this cheat sheet.

That’s not to say that you should always use XPath as your only location strategy. I also use ID or Classname wherever possible. I find these elements to be consistently named. And less likely to go MIA between test execution.

Selenium is the best-coded test automation tool for manipulating web browsers. But to use it effectively. You need to be aware of its challenges, potential dangers and ways to overcome common obstacles.

Hopefully, this post has helped with that. If you have your own tips for overcoming common issues in Selenium. Feel free to leave them in the comments below.

• Category: Software Testing