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-testsshell
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”.