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