Most blog posts and help forums will tell you to avoid testing against Internet Explorer at all costs. I tend to agree, but if you’re like me it’s simply not an option. Another issue is the most folks have problems getting started with Selenium WebDriver with Visual Studio, C#, with IE.
Due to the nature of my work, not only must I run against IE, but it’s the only browser our application supports, so there’s no way around it.
If you’re working under similar circumstances, you may be struggling with how to make your tests more reliable against IE. I recently spoke with Jim Evans, the guy behind the Selenium.Net bindings and the IEDriver to ask him about this very issue.
There are a number of interesting things I gleaned from my recent TestTalks podcast episode 28 on how to succeed with Selenium and IE.
Here are some highlights from my conversation with Jim:
Selenium and IE Synchronization Issues
One of the biggest challenges that I have found people struggle with is that their test scripts run fine against Chrome and Firefox but not against IE. Turns out the most common cause for this behavior is Synchronization.
For example, your script may look for an element and Firefox and Chrome are fast enough to render it and find it in the DOM when you ask for it, but Internet Explorer is just slow enough that your Selenium code ends up running too fast while attempting to find the element, and then it’s not there when you ask for it.
To handle this situation, it is recommended that you use one of the WebDriver wait methods, which means that you provide the wait with a condition that you check for to be true, and the driver will poll that condition to be true before continuing on. So it checks for the condition for a very short time. If it finds the element it continues, or it will continue to poll for the element every few seconds until the element is found or it reaches the timeout limit you set it to wait.
This is superior to a Thread.Sleep-type wait, because rather than wait the full time specified regardless of whether the element appears quicker, then the wait is set. This makes your tests more reliable and saves your run time execution.
The only time you might want to use a Thread.Sleep is if you’re debugging and want to quickly check to see if adding a wait helps your script. If it does, that means that you should replace the Thread.Sleep with a more efficient wait method.
The only time I would use a Thread.Sleep is if I have an actual requirement that reads like, “Thou shalt wait 60 seconds before proceeding.”
Selenium and IE CSS and JavaScript
Occasionally you may have to support running your test against an older version of Internet Explorer. There are some things you’ll want to be aware of in these situations.
First, the IE driver is version-agnostic, but you might have an issue with older IE versions and CSS locators. Current versions of IE have support for CSS 3 selectors, like last-of-type or first-of-type. Older versions of IE do not support those selectors. So if you know you’re going to be testing an older version of IE you may want to use a different locator. To see which versions support the CSS3 selector, the Can I use website is a great resource.
Selenium and IE Performance Issues
Some other challenges are JavaScript-heavy test suites; there are some issues with the 64-bit version of the Internet Explorer JavaScript engine in certain version of IE that cause them to be much slower than the one used in the 32-bit version of IE.
You don’t need to do anything; just be aware that you may have performance issues with 64-bit IE. You could also get around this by using parallelism to run your test suite across multiple machines.
IE Configurations for Selenium
Some other common IE things to look for are configuration issues, and properly configuring Internet Explorer to work the IE driver. In particular, there’s a requirement that you must set your protected mode for the browser to function correctly.
This is actually a well-documented issue, but in my experience it’s what causes the majority of issues my team encounters. I’ve actually created a video for the top three IE issue and configurations how to resolve them.
Browser vendors own Selenium Driver implementations
In the near future, browser vendors will be responsible for maintaining their own driver implementations of Selenium WebDriver. There is currently a W3C draft specification for WebDriver, and once it’s approved it will become a W3C standard. Once it’s a standard, it will give browser vendors a specification they can use to implement as part of their browser delivery — giving them a web driver that is part of their browser!
Chrome is already doing this by with Chromium. Mozilla is working on their version of the driver, which they’re calling Marionette. Microsoft implementation is available for IE11, but it’s still in the experimental stages — the W3C standard is still in an early editor draft version — so it may not include all the Selenium functionality as of yet.
My hope is that once Microsoft becomes fully involved with their own IE driver implementation that the automation of IE will become much easier.
How you can help contribute to Selenium
Many people have been asking for Selenium 3.0. To date, 3.0 is not ready, even though it was announced last year at the Boston 2013 Selenium Conference. UPDATE: Selenium 3.o beta has been released.
It’s important to remember that the contributors to Selenium are not paid, so the next time you feel like complaining about it, you should instead volunteer your time to help out. (The easiest way to get started helping on the Selenium project is to join the Selenium IRC chat channel #selenium on the irc.freenode.net network and asking how you can get involved.)
Final Selenium IE Thoughts
If you need to run your tests against IE and other browsers, I suggest you begin by developing against IE. That way you’ll know that your tests work against IE and should therefore easily run against Chrome and Firefox.
To listen to the full interview with Jim Evans, listen to the latest episode of TestTalks: http://www.testtalks.com/28
