A Survey of the PHP and Selenium landscape

With Py.Saunter well on its way, it’s time to start work on Saunter.PHP. The various roles and responsibilities of a driver vs. runner vs. framework is a separate post, but for now I’ll just say that the actual browser driver (Selenium) should be distinct from the framework. Which means the first step for Saunter.PHP is to determine which browser to use. Easy, right?

Ha!

You see, PHP has the healthiest ‘scratch an itch’ spirit of Open Source and there are at least five (5!) projects to choose from. (And I’m about to add a sixth; more on that later.)

Selenium Remote Control

There currently isn’t an ‘official’ Se-RC binding, though I believe there was one that came with releases a couple years ago. (All the language bindings were actually generated using XSLT from a common source.)

  • PHPUnit – These are the de facto Se-RC bindings since they come with the de facto xUnit framework for PHP. But there is a lot assumptions that come along with it, which is fine if you want to use PHPUnit only, but if you are trying to build a framework around it, it is less friendly.
  • Testing_Selenium – Seems like a nice driver — until you try to use it. There are some pretty nasty bugs (like commands claim they are ok regardless of what the server says) and it is essentially an abandoned project. It is also under the PHP License which isn’t very friendly.
  • PHP-Selenium looks like a pretty basic (in the good sense) driver.

If only Testing_Selenium was reliable as PHPUnit.

Selenium WebDriver

Selenium doesn’t have anything resembling a sanctioned Se-WebDriver implementation. So three projects have stepped into the void.

  • php-webdriver-bindings – Uses the JSON Wire Protocol, APL2 licensed and has wrapper for the Se-RC. It seems to be out of sync with the protocol though. There is some tests and an example script but the vast majority of the protocol is untested. Some of the methods also require you pass in strings as an array — which is a usability atrocity — just accept the string and do the cast in the driver.
  • WebDriver-PHP – Didn’t really look too hard at this, but it has Sauce Labs integration built-in. Not sure what license it is with either. The actual implementation looks not too bad, though the InitAtSauce vs. InitAtHost vs. InitAtLocal methods imply that it had crossed the driver-framework divide. Which when you are looking to write a framework isn’t something in its favour.
  • php-webdriver – No tests and no license was pretty much a nonstarter. Also has the annoying ‘need to pass in an array’ trait. The example does show method chaining which is nice. Update – it is now Apache 2 licensed it seems.

Conclusion

So.

There are a lot of options when choosing a driver, but none are quite satisfactory. Either they do more than just a driver or have a mystery license or a less-than-friendly public API implementation. Which means I’m going to further muddy the space and make another Selenium PHP binding the goal which will try to take the best ideas of each.

  • APL2 licensed
  • Friendly API (no passing in arrays)
  • Consistent API between Se-RC and Se-WebDriver
  • Only drive browsers

…and then I’ll wrap it in a framework.

Update 9/28/11 – The ‘php-webdriver’ project is now under the auspices of Facebook. But everything else about it remains the same.

Update 9/28/11 – The ‘php-webdriver’ project has been licensed under Apache 2. Now if only they would add tests and not force array creation into the user-space.

Update 10/16/11 – Added another RC driver

Comments 6

  1. Philip Schlesinger wrote:

    php-webdriver was updated ~21 hrs ago — changes to apache license version 2.0

    http://www.flickr.com/photos/66524440@N08/6192046883/

    Posted 28 Sep 2011 at 11:25 am
  2. georg k wrote:

    Hey Adam,
    Thanks for the overview & “non”-recommendations which php driver to use for selenium 2.0.

    I recently asked the SauceLabs Guys and the pointed me to your blog, without recommending any solution. (which quite dissapointed us).

    Q: How far did you proceed on your plan on making “another Selenium PHP binding” ?

    regards Georg

    Posted 11 Oct 2011 at 7:03 pm
  3. adam wrote:

    At this point I think I’ll be using the Facebook bindings; but wrapping it in a don’t-need-to-pass-in-an-array facade. I’ve also continued to use the Testing_Selenium driver but have wrapped in to check error codes and other nice things I wanted.

    Posted 11 Oct 2011 at 7:06 pm
  4. Jim Wiggs wrote:

    I’ve been using the Testing_Selenium framework but am beginning to realize I may have bet on the wrong horse. In particular I’m running into problems with results from getEval being randomly truncated. I’ve written JavaScript to execute using getEval that can capture an image out of the DOM and return it as a Base64-encoded string, but frequently I will not get the entire string back.

    Also, it appears that the Testing_Selenium works with the old Selenium RC, not the new WebDriver. I really would like to standardize on a set of PHP bindings that will be solid. What do you suggest?

    Posted 19 Oct 2011 at 11:13 pm
  5. Spudley wrote:

    Another option to consider: Mink (http://mink.behat.org/).

    Mink provides a PHPUnit wrapper for Selenium (both v1 and Webdriver). So far, so good; the API seems to be reasonably well thought out, and it integrates well with Behat, the BDD framework from Symphony.

    But it has a wildcard feature that makes it much more interesting: it supports multiple browser testing platforms from the one single API. In addition to Selenium, you can also run your tests using Sahi or Zombie. Just change the connection details, and you can use the same API to run the same tests in any of them (with some caveats based on what the various platforms support).

    Very neat.

    Posted 19 Apr 2012 at 10:50 am
  6. cystbear wrote:

    Please add this, best one
    https://github.com/instaclick/php-webdriver

    Posted 16 Jan 2013 at 5:49 pm

Post a Comment

Your email is never published nor shared. Required fields are marked *