Interactive selenium testing

The problem

Location of elements

When I started using selenium, I noticed that it is not easy to do it right. First you start with IDE, but you notice, that the IDE does not really record a lot. In a next step I added firebug, and started analyzing how the elements where to be located: either by tag, id, class etc.

Junit testcase

With this information I could then create my junit testcase:

 @Test
 public void testMapView() throws Exception {

  //assert that we cannot see submenu of MapCreator
  elem = driver.findElement(By.className(SeleniumConstants.MAP_SUB_MENU));
  String style = elem.getAttribute("style");
  assertTrue("Element must have style display off.",style.matches("display: none.*"));
  logger.debug("Located element " + SeleniumConstants.MAP_SUB_MENU);

  //find menu and click on mapview
  elem = driver.findElement(By.id(SeleniumConstants.MAP_CONTROL));
  actions.moveToElement(elem).click().perform();
  //assert submenu is shown now
  elem = driver.findElement(By.className(SeleniumConstants.MAP_SUB_MENU));
  style = elem.getAttribute("style");
  assertTrue("Element must have style display on.",style.matches("display: block.*"));

Now this all works very nice, only, not after the first time. It took many iterations to get here.

selenium iterations

Usual failures are, that element cannot be found:

org.openqa.selenium.NoSuchElementException: Unable to locate element: {"method":"id","selector":"

or, that you cannot click on an element, as it is not the top element or not visible:

Element is not currently visible and so may not be interacted with Build info: 

This kind of failures eat a lot of time. The forced me to analyze, use firebug, make some changes, and to restart my junit testcase. Every failure caused me to restart my testcase ...

The first solution: eclipse debugger

I started running my testcases from eclipse, in debugging mode. I put my debug point at the location where it started to get interesting. Now I could see the exact state of my application. Also, with the debugger expression viewer, I could create expressions, that actually executed something:

(new Action(driver).moveToElement(elem).click().moveByOffSet(100,100).click().perform()

Althoug the expression viewer is actually to discover calucated values, you can also use it to pass on new commands. It is running in the context of your JVM, so can directly pass commands to your selenium driver.

Disadvantage of debugger expressions

This helped a lot, I could do better analysis, and try out before adding it to my test code. However, on any exception or failure, my debugger threw an exception, and I was out. I still had to restart my jvm. The problem is also with junit: when you get an exception, your test is over. No way to retry.

The new solution: groovy console

The new solution is a lot more elegant:

• No junit test, but just a simple main program
• Initialisation of selenium driver takes place in program, then control is handed over to a groovyconsole
• Groovy allows for runtime compilation
• Test scripts can be saved and replayed.

This was the real winner, and I still love it. Suddenly test automation with selenium starts to make fun again.

A simple example

When I start up my selenium-groovy, I get a swing groovy console that allows me to type selenium commands:

These are just a few lines of selenium. But the nice thing is: if they are wrong, you get a failure in your console, and you can just retry. Likewise, you can select only a few lines of your script, and only run those again.

Coming topics

In future blogs, I will continue on this topic:

• code explained to setup the groovy console
• how to setup your maven project to get this working
• making your own utilities
• a few more examples
• running your recorded scripts in junit tests.

Stay tuned!