Extending Selenium

October 5, 2008

I think Selenium is great for acceptance testing websites. But I’ve found it can be pretty slow to do certain things in Internet Explorer, in particular anything to do with xpath queries.

Something we need to test in work is that a particular CSS class is set on a particular element. Currently Selenium doesn’t provide a way to do this without using an XPath query. However, it is fairly easy to extend Selenium and implement this without the use of XPath. The basic idea is to use Selenium’s getEval method within an extended DefaultSelenium and wrap a particular call inside a standard Java method.

Here’s an example of what I’m waffling on about:

public class ExtendedSelenium extends DefaultSelenium {
  public String getCssClass(String elementId) {
    return getEval("{selenium.browerbot.findElement('" + elementId + "').className;}")
  }
}

Selenium provides the browserbot object, this has many handy methods that work cross browser. They tend to be pretty efficient too. However you’ll have to be careful that any extensions you write, are either only going to be run on a single browser, or you write cross browser code.

Have fun!

Advertisements

Deleting code – what the inspector wasn’t told.

September 17, 2008

I like deleting unused code, it’s fun and satisfying. IntelliJ is brilliant at helping discover unused code too, with it’s code inspector.

Oddly, some developers go to great lengths to try and stop tools like this being able to identify if code is actually in use. One of the common techniques is to stick a class name into a database table – the reasoning for this tends to be ‘so we can change it dynamically’. This quite rightly induces a certain amount of fear in developers when it comes to deleting any code, as it might be in use.

A solution: Move the code in the database back into code.

By writing a script that runs a series of select statements on each of the columns and tables that contain the class names, then you can generate a java file that in turn has a static reference to each of the classes. This can then temporarily be included in your source tree, and the inspector can get on with it’s job. Lovely!

I’m sure this can be expanded to cover field/method names too with a little bit of generated casting.