Debugging Selenium Tests

Selenium Tutorial Table of Contents, Next Chapter, Previous Chapter

Selenium tests are challenging to debug because of the distributed nature of the Selenium environment. By the time a test fails it has moved through the Selenium client, to the Selenium Server (or Selenium RC in Selenium 1,) into the browser, into the Javascript engine, and into the function of the application. Testers are usually 5 degrees of separation away from the cause of the problem.

When Selenium throws an exception, the error message will usually indicate the part of the Selenium test script that encountered the problem. I usually begin debugging by understanding the error message. If that is not fruitful then I view the source of the browser at the point of the error. I then add Selenium commands to understand the state of the Web application under test. For example, I add assertion or verify commands to check that certain elements exist within the DOM. TestMaker adds a savePage() method to save the current DOM to a file that I may then inspect.

The following are problems I often encounter while using Selenium:

·         Element is not ready yet. Selenium reports 'Element Not Found'. In Ajax environments this is usually caused when  Selenium test is out of syncronization with the Web application. I solve this by adding waitForElementPresent commands prior to each click, type, assert, and validate command.

·         Window title is unknown. In Ajax environments pop-up windows are common. Selenium needs to identify the dynamically created Window to route client, type, and other commands. Selenium needs the internal Javascript function call created Windows title, and not the <title> tag name. Look at the Javascript that creates the new window for the Window title. It will often look like: open (URL, windowName );

·         Selenium breakpoints. Right-click on a Selenium command in Selenium IDE or TestMaker Object Designer to set a breakpoint. Once Selenium IDE or Designer hits this breakpoint you can inspect the application state using the Firebug debugging utility.

·         TestMaker Object Designer evaluate tab. Designer lets you make Javascript API calls to the Javascript engine running the Designer or the Javascript engine running the application's Ajax Web objects under test.

·         Pause. (As in NEVER USE PAUSE!) Pause is a Selenium command that makes the running test script wait a given number of seconds. Since the browser is fully threaded any operation could be happening at any time. Pause will work one way for one Ajax application and another way for another application. Use waitForElementPresent as an alternative to Pause.

·         Space and Case sensitive commands. Selenium is finicky for spaces and other typos. Assert commands have frustrated me where the input to an assertEquals method has an extra space or one character is upper case when it should be lower. Put on those reading glasses and look carefully at your Selenium commands and parameters.

·         Browser specific problems. Each browser is its own environment, including XPath evaluation engines, DOM rastering engine, Javascript engine, and add-on components such as Flash component players.

Learn many more Selenium debugging methods at the Advanced Selenium Workshop. It's free!