What's next for wp-browser?

What’s going to be in wp-browser (and its ecosphere) next versions.

WP-CLI package

My side project of a wp-cli wp-browser specific command moves on; at this point scaffolding plugin tests requires no more effort that typing:

wp wpb-scaffold plugin-tests

Working on it led to the development of an interactive mode for the wpcept command and explicit theme testing support; with those pieces done completing the work to have a command to scaffold theme tests as well is the next logic step and one of the original goals.
Adding some CI file scaffolding for Travis CI could be a further step.

Better multisite support

I run into “meh” moments every now and then when testing multisite installations with wp-browser.
Those are usually solved with little effort but it’s worth spending some time to explicitly support and solve those issues in the package; e.g. network wide activated plugins and options override.

Gherkin bottom up

It’s not been long since Codeception introduced support for the Gherkin syntax and I fell in love with it.
The only issue is that due process is to write the features, run the step generation command, implement the steps in PHP then run the behaviour tests again.
There is nothing wrong with this when I work alone but it kinda breaks the flow when working in a team where, ideally, features could be written by non developers; the flow breaks then down to:

  • non developer writes features
  • non developer runs features
  • non developer get non implemented steps notice
  • non developer delegates developer to implement steps
  • developer eventually implements steps
  • non developer runs features
  • repeat for (almost) any new feature or non developer writing features

This is a “top to bottom” approach. Providing anyone writing features a list of implemented and supported steps is a solution but one that must be maintained from developers.
What I would like to do is to start from what Codeception module methods I already have and build (automagically) the steps from those.
Take the PHPBrowser module and its amOnPage($page) method, it easily translates in a Gherkin step like:

Given I am on page '/foo'

but also to

When I am on page '/foo'

I’d have to implement the same step twice; no biggy here but not very DRY. I’d like to run a command like this to build steps from all the modules loaded in a suite, e.g. the acceptance one:

codecept gherkin:steppify acceptance

If my acceptance suite uses the WPBrowser, WPDb and helper modules I’d like to have a step generated for each publi method in each module.
Plus I’d like to be able to define in code or in a configuration file if a method should generate Given, When and/or Then steps; in the case above PHPBrowser::amOnPage($page) makes sense as a Given and When step but not as a Then step.
By default methods would generate steps for all three cases but using a notation like @gherkin that generation would be constrained (example from the WPDb module):

/**
 * @gherkin then
 * Checks for a post in the database.
 *
 * @param  array $criteria An array of search criteria.
 */
public function seePostInDatabase(array $criteria) {
    $tableName = $this->grabPrefixedTableNameFor('posts');
    $this->seeInDatabase($tableName, $criteria);
}

/**
 * @gherkin given
 * Inserts a post in the database.
 *
 * @param  array $data An associative array of post data to override default and random generated values.
 *
 * @return int post_id The inserted post ID.
 */
public function havePostInDatabase(array $data = []) {
    $postTableName = $this->grabPostsTableName();
    $idColumn = 'ID';
    //...
}

This would make it easy to produce a list of available steps and would avoid duplication of documentation.
This will probably be an extension or separate command to allow re-use.
How this should and could work I have no idea about.

Documentation

I know for experience people does not read documentation (ever) because time and reasons but I’m willing to spend some time improving it probably making a step by step documented process out of it.
“Writing documentation” is not enticing as “write about your effort to implement a WordPress website dedicated to documentation and relying on crazy but tested hacks”.