Wednesday, 23 March 2011

Selenium 2 makes automation debugging easier

One of the parts of Selenium 1.0 that I never enjoyed was debugging automation that didn’t work. I had to faff about creating custom Firefox profiles with Firebug installed and set to go through a proxy.
Selenium 2 makes all of that so much easier. With the code below, my test runs through a proxy server on port 8081 and has Firebug installed so that I can breakpoint my test and then go debugging around in the browser DOM, debug the JavaScript to make sure events get fired, etc. etc.
I found most of the information to do this on the Selenium Forums
The code should be easy enough to follow if you are already using Selenium 2

import org.junit.Test;
import org.openqa.selenium.Proxy;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.firefox.FirefoxProfile;

public void FirefoxUseExtensions() throws IOException{

  // setup the firefox proxy to point to Burpsuite
  // on port 8081

  Proxy localhostProxy = new Proxy();

  // Prior to running the test
  // Download the firebug extension file
  // to a local folder

  String extensionPath = System.getProperty("user.dir") 
      + "/"
      + "firefoxExtensions/firebug-1.6.2.xpi";

  // create a custom profile

  FirefoxProfile profile = new FirefoxProfile();

  // set the profile to use the proxy settings


  // stop firebug showing the first run
  // screen by setting the 'last version'
  // to the current one downloaded
  // try without this and see what happens!

  profile.setPreference("extensions.firebug.currentVersion", "1.6.2");

  // add the extension to firefox

  profile.addExtension(new File(extensionPath));

  // start firefox with the custom profile

  WebDriver driver = new FirefoxDriver(profile);

  // go to your favourite testing web site




  1. One thing that troubles me with solutions like this is the fact, that I shouldn't debug my automation, but rather have it properly tested by some unit tests in itself. Mentioning this may start a whole thread of argumentation in some locations (and some clients) whether testers who just record tests should be able to do so, blabla.

    To me the fact that software test automation - even with tools as Selenium which may help us with it - is still software development, and in software development we learned how to avoid debugging most of the time by doing test-driven development. So, I test-drive my test automation code as well when it becomes complicated.

    Then the problem is, that with a framework a selenium you may get troubles unit testing your code, but that's a different conversation.

    Thanks for the note of caution Markus,

    I clearly don't test drive most of my automation framework. I do test drive portions of it - mostly support functions.

    And sometimes I do need to figure out 'why on earth isn't this "£$&&!*"£" script working'. Clearly having unit tests around it might help me pinpoint problems faster. In this particular case I wasn't sure if the application or automation was at fault and needed to debug through to make sure. Unit tests might have helped me do this faster.

    I'm certainly interested in reading more about your TDD approach to automation, have you written it up anywhere?

    If you only TDD your automation when it gets complicated, I doubt that you would have had any tests in the circumstances I found myself in, as it wasn't complicated automation.

    I also use automation to support my manual testing, so I want my manual testing tools available when the automation takes me to the 'manual' part, so I find this a good way of doing that.



  2. Thanks -- just out of curiosity, what proxy are you using here to help debug?

    I also have done TDD selenium automation. The approach I've used is to have an "internal" suite that solely focuses on element locating and internal helper methods. That being said, I try to write as many helper classes as possible without requiring a browser and DOM wherever possible. Obviously, only sometimes possible.


  3. Alan Richardson11 June 2011 at 09:13

    Hi Jason,

    I would have been using burpsuite

    or Fiddler

    I generally use burpsuite though as that runs cross platform and Fiddler is .Net and Windows only - but it depends what I'm trying to achieve.

    For test debugging I would have used BurpSuite.

    Thanks for the comment.


  4. Ahh, I presumed from your other posts that you'd be using burpsuite. Thanks for confirming....I tend to use Charles a lot, but am curious to give burpsuite a try!