My current client runs a major consumer-facing web application, and I’m helping them build a suite of browser-automation tests using Selenium. We’ve had a lot of problems with test failures caused by intermittent page load timeouts, though — the application includes a LOT of external resources (1×1 pixel GIFs, javascript, etc.) used to enhance the application’s functionality and track its users’ behavior. These resources are hosted by other organizations, and unfortunately, they don’t always load quickly and reliably — any one of them can cause the page load time to exceed our default timeout of 30 seconds. This…well, this pretty much sucks.
Ideally, we’d make the inclusion of the external resources a configuration property, so that they would only get included in environments where they matter — production, staging, and environments dedicated to manual QA testing. We definitely DON’T want these resources included where we’re running automated tests, (that is, local developer and continuous integration environments). In fact, this ability is a planned enhancement to the application… but it’s going to take a little while to get it implemented. Meanwhile, we’d been unable to maintain a green CI build for more than two or three checkins. We needed a more immediate fix.
Fortunately, we came up with one — we’d use the /etc/hosts file to fool the browser into thinking that the servers hosting those resources were unreachable, thereby preventing it from waiting for them to load (and potentially exceeding out test timeout while doing so). Here’s how:
- We made a list of the remote hosts that the application refers to. We dumped the HTML for the application’s home page into a file and extracted anything that looked like a URL (that is, started with http(s)?) on to a separate line. We then stripped off the protocol, path, and query string parts.
- We prepended each line with “0.0.0.0 “
- We then fired up our favorite text editor and copy all of the lines into your /etc/hosts file. On Unix-y operating systems, you’ll probably have to use “sudo”. On Windows, you’ll have to dig deep into the bowels of the system installation directory to find the file — use this page as a guide.
Result? Not only have we significantly improved the reliability of the build, we also reduced the length of the build by more than 20%! Not bad for a few minutes’ work. Keep in mind that you’ll have to make this change on every machine where your Selenium server runs — on each of your local developer machines, and on any that you use for your continuous integration environments. Also, even though we’re using Selenium, this technique will work with any other browser-automation framework, too.
But remember folks, this is a dirty hack — but if you can’t modify the application under test and you’re desperate to stabilize your build, it might be worth a shot.
