Wednesday, January 11, 2012

WebTestingExplorer Documentation Moving Forward

I started writing some documentation for WebTestingExplorer in the site Wiki. Because I would like people to start trying it out, I'm hoping that it will help them get started without necessarily having to pour over all the code and Javadocs. The core API documentation is (and always will be) in the Javadocs, but I will use the Wiki to explain some of the higher-level concepts and design philosophies. So if you get the chance, download, build, try it out, and, of course, let me know how it goes.

Sunday, January 1, 2012

Suppressing Firefox favicon Requests from WebDriver

Right now, WebTestingExplorer only works with Firefox. There are a couple of reasons for that which I won't go into here. Anyway, we decided to wire our HTTP requests to go through a proxy by default. This allows us to look for specific status codes, presumably "undesirable" ones like the 500-series, or possibly 404's.

When we did this and pointed the tool at a specific URL, the first thing we noticed was Firefox firing off a bunch of requests to various locations on the target site fishing around for the favicon, most of which (kind of by definition) ended with a 404. I'm surprised that for as long as I have used Firefox attached to a proxy for testing and debugging, I had never taken note of this before. In this case, it's really annoying -- after all, one of the points of using the proxy in the first place was to verify that all requests came back with a valid response.

The first thing I considered was adding special-case code for all favicon requests in the handlers for the proxy. That seemed kind of lame, so the second thing I thought about was looking for a way to suppress the requests in the first place. It turns out that there are Firefox preferences for this -- browser.chrome.favicons and browser.chrome.site_icons -- as described here.

I have two main points left for this post. First, I wanted to show the code for how set these preferences in Selenium WebDriver when you build your FirefoxProfile:

final FirefoxProfile profile = new FirefoxProfile();

// The following preferences control Firefox's default behavior of sending
// requests for favicon.ico, which results in lots of bogus 404's for sites
// that don't have favicons. 
profile.setPreference("browser.chrome.favicons"false);
profile.setPreference("browser.chrome.site_icons"false);
    
FirefoxDriver driver = new FirefoxDriver(profile);

Second, I will pitch my opinion that in most automated testing scenarios, you probably ought to be suppressing favicon requests from Firefox, even if your site actually has one. A good way to do this is to save the preferences into a custom Firefox profile used for automated testing. If you don't already have one of those, you should. I will try to provide some tips on how to maintain and use one of those in a future post.

Introducing WebTestingExplorer

My friend and I recently started working on a new open-source project, WebTestingExplorer (hosted on code.google.com). We are setting out to do a high-quality, industrial-strength implementation of some of the ideas we worked on in graduate school at the University of Maryland, specifically applied to web application testing. The super-high-level idea is to incrementally "explore" the web user interface, simultaneously looking for bugs and generating test cases. Although the project is in a very early state, the current implementation can do a few useful things, such as:
  • Detecting unexpected HTTP status codes and Javascript errors during exploration.
  • Generating and replaying regression test cases, looking for differences in state.
A few tenets we have adopted are:
  • Most everything regarding the exploration and test case replay process is configurable.
  • Configuration is done primarily via code, not command-line arguments or XML files.
  • The application-under-test is inherently "testable" (or we can make it so), such as having unique id's for important HTML elements, and hooks that enable reliable timing of actions.
If you are interested in automated test case generation and/or web application testing, feel free to start playing with it and sending feedback through the Google Code project. Although the primary vehicle for project communication will be the Project Wiki, I hope to blog here about some of the interesting issues we encounter. So until next time...