WP-CLI WPBrowser integration good enough to ship.
In my latest post I’ve presented the draft idea, and draft code, to allow the use of wp-cli in functional and acceptance tests.
The reason while I’m excluding unit and integration tests is that the first type should not require WordPress at all while the latter should rely on a module like WPLoader to access and manipulate WordPress data.
I’ve knowingly left some limitations in place for the WPCLI module and accordingly so: wp-cli is a full blown tool to do any kind of thing with WordPress and not all what the tools allows makes sense in a test that’s supposed to be isolated and repeatable; e.g. hard rewrite of the permalink structure.
The tool, even wrapped and limited as it is in its embedded form, still retains much of its power.
The wp-browser package specifies the wp-cli tool as one of its dependencies and as such a working and functional installation of wp-cli is not required.
While I do not see how someone developing anything on WordPress could not have it installed it makes sense in a continuous integration environment like Travis CI.
It should not raise conflicts with the resident installation of wp-cli but time will tell.
As I will iterate over the unavoidable bugs I will have introduced in this new release (a skill of mine) I will walk the path of wp-cli love a little further trying my hand at the creation of a wp-cli package: I’d very much like to be able to write
wp scaffold plugin-wpbrowser-tests.