Configuring WPBrowser for Travis CI.
Two sides of the process
In my previous post about Travis and Continuous Integration (CI) I’ve detailed the script required to set up Travis to run all the tests and outlined the requirements it needs to fulfill.
Codeception allows running multiple types of tests with a single command but the requirements of each test type will differ greatly; depending on the project some of those might not be required at all. Running the typical PhpUnit powered unit test will usually only require PHP but moving up to integration tests the WPLoader module will add an accessible MYSQL database to the requirements; further up a module like WPWebDriver dedicated to acceptance testing will rely on a fully working web server like Apache.
Understanding Codeception “distribution” files
When the default Codeception scaffold command runs, e.g.
codecept bootstrap, some files and folders will be created in the project root (see more about this in Codeception installation guide).
The general configuration file
codeception.yml will sit in the project root while the
x.suite.yml configuration files dedicated to each suite will be created in the
tests folder; the location of the files may vary due to a particular project configuration, suites and needs but I’ve described the general behaviour.
In a typical installation of wp-browser the
wpcept bootstrap command will scaffold what I feel is a sensible choice of suites and configurations for a WordPress project; specifically the
acceptance suites and respective configuration files.
The suites configuration files are but, usually, tied to the local machine set up and might not be suited to work in a CI environment like Travis.
To fill this gap Codeception allows for “distribution” versions of each configuration file to be shared across machines to provide a default configuration fallback; to make an example my local
tests/wpmodule.suite.yml reads like this:
class_name: WpmoduleTester modules: enabled: - \Helper\Wpmodule - WPDb: dsn: 'mysql:host=docker-mysql;dbname=wpbrowser' user: 'root' password: 'password' dump: 'tests/_data/dump.sql' populate: true cleanup: true reconnect: false url: 'http://wp-browser.dev' tablePrefix: 'wpbrowser_' - WordPress: depends: WPDb wpRootFolder: "/Users/Luca/Sites/wordpress" adminUsername: 'admin' adminPassword: 'admin'
While this is the
wpmodule.suite.dist.yml file pushed to the wp-browser repository:
class_name: WpmoduleTester modules: enabled: - \Helper\Wpmodule - WPDb: dsn: 'mysql:host=localhost;dbname=test' user: 'root' password: '' dump: 'tests/_data/dump.sql' populate: true cleanup: true reconnect: false url: 'http://wordpress.dev' tablePrefix: 'wp_' - WordPress: depends: WPDb wpRootFolder: "/tmp/wordpress" adminUsername: 'admin' adminPassword: 'admin'
The first file is ignored by Git and is not pushed to the wp-browser repository, Codeception will read, when looking for the
wpmodule suite configuration, the “distribution” version of it, the
The settings specified there, like the database credentials or the URL of the WordPress test installation, should match those set in the Travis configuration file.
Before moving to the I’d like this plugin to enable Travis CI on it I will refactor the set up code used to set up the WordPress installation for wp-browser test in a separate package that will contain re-usable code.