There is no way to directly get HTTP status codes in the WebDriver API (see the lengthy discussion in issue #141). But that doesn’t mean you have to leave Selenium or go without any status codes in your test scripts.
In fact, some of the supported methods - proxies and tightly coupled headless browsers - should make you feel at home if you’ve transitioned from Selenium RC, or are comfortable with traffic sniffing proxies.
WebKits that Play Nicely with Selenium
This can seem like both the most straightforward and heavyweight solution. The Selenium core devs point out that Fiddler and BrowserMob are supported OOTB in WebDriver, and setup is relatively simple:
To take it a little further, Jim Evans, maintainer of the Selenium .NET bindings, has given the .NET crowd an excellent
...Or Grab the Error Text from the Actual Browser
If that’s more than you need, then you can stay in WebDriver and use this common hack: Just grab the error code displayed by the actual browser. It is good enough for returning errors so long as you know the text to be displayed and where it will
Here’s a simple example:
So What Should You Do?
Parsing response data from the page is the easiest way to extend your current use of Selenium to grab some basic HTTP status code data; there are no proxies to set up, and no new test frameworks to learn.
But you will miss any errors not displayed on a page, likely including all 3** redirects. Using GhostDriver to handle PhantomJS will handle status code returns, and keep everything in CI in Selenium—and it’s in that sense the best tool for this job. But you may already have some testing proxies set
Alex Entrekin served on the executive staff of Cloudshare, where he was primarily responsible for advanced analytics and monitoring systems. His work extending Splunk into actionable user profiling was featured at VMworld: "How a Cloud Computing Provider Reached the Holy Grail of Visibility". Alex is currently an attorney, researcher