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.
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 three part guide on how to hook up Fiddler to a test page and Selenium, begin filtering for basic status codes, and customize for redirect issues and cross-browser testing.
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 display, and aren’t interested in all of the routing through a redirect path.
Here’s a simple example:
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 up, since they do let you do a little more real-world test building, like white/black list and simulate load and slowdown conditions. And of course that doesn’t mean you can’t use GhostDriver to drive PhantomJS with WebDriver in a proxy, which you can of course host and automate in Sauce and AWS.
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 and writer based in Santa Barbara, CA. He holds a J.D. from the UCLA School of Law.