WPBrowser scaffold WP-CLI command 03

Laying out the base for an interactive WPBrowser scaffold process.

A format that’s not going to fly

The development of the wpcli-wpbrowser-tests package for wp-cli goes on in its [Behat] (!g behat php) powered might but there are limits to the format.
The package aims at making the process of scaffolding WPBrowser based tests for a WordPress theme or plugin easier using a command similar to the wp scaffold plugin-tests one the WordPress console tool offers.
WP-CLI “interface” for commands is getopt based allowing the user to supply options in the --option=value format; with all the possible configurations the growing wp-browser library for Codeception might have maintaining, and using, such an interface would be a chore.

Development so far

I’ve implemented, for the time being, just one command for the package:

wp wpb-scaffold plugin-tests

and its typical usage is meant to be one where I browse to the plugin root folder and launch the command from there:

shell
cd /usr/var/www/wp/wp-content/plugins/my-plugin
wp wpb-scaffold plugin-tests
shell

The command will update the existing composer.json file, or create a new one, to add the lucatume/wp-browser development dependency and then will launch the composer install command.
After Composer has finished the download process the command should launch the wpcept bootstrap command to scaffold all the files wp-browser and Codeception will need to run tests.
This latter process in itself is as straightforward as setting up Codeception is: fine for me but not for everyone.
In a typical scenario what would happen, should the user want to setup unit, integration, functional and acceptance tests, is that the user creates a couple databases, creates some dumps, sets urls, access credentials and paths around the configuration files and then launches an empty test run to check everything is working.

In command terms

The amount of variables and combinations required to set up the suite cannot simply be modeled using WP-CLI option-based interface and there is no point in not leveraging what’s already there.
Any Codeception command, and wp-browser by extension, is based on the Symfony console component and as such offers an array of powerful possibilities to put interactive command-line interfaces in place.
In command terms this means that my next effort will be to add the --interactive option to the wpcept boostrap commands; this will offer the double benefit of adding something much needed to WPBrowser while also making the wp-cli interaction possible and “smooth”.

Next

I will move from work on the wpcli-wpbrowser-tests package to the wp-browser package to put in place the interactive mode.

I appreciate your input