Final touches on a local setup tool I could use.
A WPBrowser setup solution
In the last days I’ve worked to extend and refine the functions of the Codeception setup command to take as many scenarios as possible into account.
codecept setup and
codecept search-replace commands are meant to be general purpose and applying to any Codeception based project; the idea is to keep them so small in focus and functions to remain versatile.
Once this “base” was laid in place I’ve moved to a WordPress and WPBrowser specific solution that should allow for developers to easily setup and share testing environments in WordPress projects.
As easy as this (provided Composer and Codeception are installed):
git pull codecept setup
I’m working to add the
wpcept setup:scaffold command to WPBrowser.
The command tries to address the opposite side of the “easy setup” giving developers a quick way to setup up a structured testing environment starting point.
Under the hood the
codecept setup command above is going through the instructions listed in a
setup.yml file and executing them one by one; some instruction are variable values requests, others are calls to Codeception commands and some are script executions.
In a typical WordPress testing scenario those instructions would ask the user for local database setup details, WordPress installation paths and login details.
Those details would then be used to replace data in test suites configuration files starting from the
codeception.dist.yml file to move to the suites configuration files (
functional.suite.dist.yml and so on) and then to the database dump files (e.g. the default
In the dump files WordPress hardcoded URLs and domains would be replaced not unlikely what the WP CLI
search-replace command would do.
Furthermore the command should take care of creating missing distribution versions of configuration files. Ideally it should be as easy as running it
and answering some questions.
I will finish tests on the command and ship its first version with some documentation attached.