An Odd Approach for Browser Specific Tests for WebDriver

I think I’m allowed to call the approach I document in this post as ‘odd’, because it is an approach I use, and I won’t be offending anyone.

Very often we want tests that only run on specific browsers.

The obvious way to do this is have some sort of ‘tagging’ facility for tests and suite creation, or manually exclude certain test methods or classes from suites.

An ‘odd’ way, which I have used as part of my course, but not in production, is the following:

@Test
public void driverGetTitleWithCSSAbsoluteFromRoot(){

  WebDriver driver;
  pageTitle = "Welcome to the Find By Playground";
  driver = Driver.get("http://www.compendiumdev.co.uk" +
                      "/selenium/find_by_playground.php");

  // try catch block added for IE which 
  // does not like starting css at html
  try{
      WebElement element;

      element = driver.findElement(
                    By.cssSelector("html > head > title"));

      // getTextNow returns "" for head elements
      //assertThat(pageTitle, is(element.getText()));
      assertThat(pageTitle,is(element.getAttribute("text")));

      if(Driver.currentDriver == Driver.BrowserName.IE){
          throw new RuntimeException(
                       "IE now allows CSS starting at html");
      }

  }catch(NoSuchElementException e){
      if(Driver.currentDriver != Driver.BrowserName.IE){
          throw new RuntimeException(
              "Expected only IE to fail on CSS starting at html");
      }
  }
}

In the above code, ‘Driver’ is a factory buy inderal online canada class I use which provides me with the current driver, and it knows what type to use from a property, so I can check what type of browser I’m using, e.g. IE, Firefox etc.

That isn’t odd though.

The ‘odd’ part is that I expect the test to fail under IE, for a condition unrelated to the assert, so I wrap the body of the test in a try/catch block. And the try/catch block is there to alert me if the behaviour of the test changes.

If the catch block is entered then I throw an exception when the browser is not IE, because I only expect IE to enter the catch block, so if any other browser does then it is a change in behaviour of Selenium WebDriver that I want to be informed about (hence the exception to fail the test).

If the try block carries on, after the assert then I have thrown an exception when the browser is IS, to alert me that the behaviour in IE has changed. In the version of IE that the test was written against, IE would always enter the catch block.

The actual test code itself is the assert in the middle, which would still ‘fail’ or ‘pass’ for different browsers.

As a sideeffect, the test doesn’t throw an error on IE, for the conditions that I’ve coded for (I expect it to fail on IE). Really it was a workaround for a limitation in the IE driver at the time, and the try/catch block was there to alert me when the IE Driver changed to allow access to elements in the <head> of the page using CSS selectors. (Which it now does, by the way).

Hope that makes sense. Even if I can’t imagine many people having the use case it handles:

  • Run the test, don’t report errors for a certain driver, unless the driver changes to allow the test to run on it.
This entry was posted in Selenium Simplified Blog, WebDriver. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *