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 unit, integration, functional and 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 wpmodule.suite.dist.yml file.
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.
Next
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.