Running Codeception tests on multiple WordPress environments

Using the –env flag in Codeception. Running tests against multiple versions of WordPress.

Suppose you want to run your test suite against multiple environments? Perhaps with different browsers or with different versions of WordPress or PHP? Codeception makes this easy with the –env flag.

This is a plugin I made that rolls back a new feature added to WordPress 4.9. I want to run an acceptance test against the latest version of WordPress, and also against a legacy version of WordPress.

Setup multiple environments

I use an Ubuntu laptop with apache2. Your mileage will vary. When I develop a website, say, I setup my laptop to redirect to a local directory on my laptop. There I keep a copy of the production site to work on.

Directions to setup multiple hosts from

On my machine, I setup two distinct WordPress installs, one at http://localhost and the other at One running version 4.9 and the other running version 3.9.

WordPress v 3.9.23
WordPress v 3.9.23

WordPress v 4.9
WordPress v 4.9

In this example, I’ll be running an acceptance test against both versions of WordPress. I’ll need to setup the YML file like this:

I use this command:
bin/codecept run acceptance -vvv --html --env remotehost --env localhost

bin/codecept is the executable [might be wpcept or codecept]
acceptance is the suite
remotehost and localhost are the envs
-vvv very very verbose [one dash]
–html report to html [two dashes]

Codeception runs:

Passing Tests!
Passing Tests!

Understanding DNS and localhost [vis-a-vi WP-BDD]

The Domain Name System [DNS] is the system a browser uses to resolve domain names like to IP addresses like A server connected to the internet generally has one IP address, usually one main domain, but it can also have many subdomains. For instance, this server hosts the domains and another blog, Both have the same IP address, but different domain names.
When an HTTP or HTTPS request is sent to the server, the request should include the host header which indicates to the server what domain a resonse is expected from. A browser like Chrome or Firefox does this automatically for the user.
Internally, once the request is received by the server, a web server, like Apache, sends each request to a particular directory, based on what subdomain is named in the host header. From there, a file is activated, and in our case, passed to the PHP parser. For WordPress, it is called index.php. On most Ubuntu WordPress setups, the main domain root directory is usually set to:
and subdomains go from there:

These are the directories [for their respective domains], which will contain the WordPress root files, especially the index.php, the wp-config.php files, and the other directories like:

Understanding this is important because if you are setting up a local development version of WordPress, you are going to want to be able to set subdomains up. Normally, you’ll have a sepearte wp-config.php file for each domain, specifying which database the domain points to.

The default setup on Ubuntu, is for the domain localhost to point to //var/www/html . Therefore, to access your local WordPress site, open a browser like Chrome, and got to http://localhost/ and you should get the WordPress install screen.

Another consideration is that most forms of testing work the best when you don’t have any state. That is, the database is either reset to a starting point, or totally scrubbed after each test. If you’re not used to this, you may accidentally delete anything you have on your site, especially if you’re using it for anything.

My personal setup is that I use http://localhost/ for unit testing, and I have another WordPress install, called where I have a database that doesn’t reset.

Directions: Setting up virtual hosts on Ubuntu 16.04 LTS.

Tutorial: Setup cloud based Dev server for PHP / WordPress using Codeception

Part of a BDD WordPress article.

These directions will setup a a Behavior Driven Development (BDD) environment, for WordPress in the cloud using Codeception. It will setup a WordPress install in the cloud, pull down a plugin from Github, and setup an IDE as well as a test suite. You can use this dev cloud environment to engage outsourcers or remote teams.

  1. Setup an Ubuntu instance, i.e. on AWS. You should be able to do this on any cloud based Ubuntu machine or laptop.
  2. Create a local key pair on your machine and connect to your instance. This is the Amazon security authentication system. The goal is a clean Ubuntu machine. You could use another service [like Google or Cloud9] or even a localhost. Open ports 4444 and 80.
  3. Install and update software.

The IDE is at: