Understanding WordPress Codeception configuration files



For a pass / fail test to be meaningful, it should test one – and only one – conceptual object at a time. It should test just one specific thing, so that if the test fails, you understand what one specific thing needs to be addressed. If the test involves more than one thing, it should be split into more than one test.

This becomes a difficult issue with WordPress, becaue many of the features that you may want to test involve several different moving parts working at the same time [i.e. the network, database, server, plugin code, content, design etc.] Testing the content will definetly fail if the network goes down. This is a problem, and the reason WordPress “unit” tests are not “true” unit tests.

WordPress Codeception deals with this problem in one of two general ways:

  • You can load a pristine WordPress install into memory usuing the WPLoader module to do unit testing.
  • You can load a database snapshot via a SQL dump file for acceptance tests and use the WPDd module, usually in conjunction with WPWebDriver and an browser driver like PhantomJS or Selenium.

Sometime you don’t require a pristine state. i.e. acceptance tests that run againsts a live external site. You obviously can’t reset the database in these cases. Create a new suite, and ignore the options for resetting the database in that test suite’s configuration with a # symbol.

If you use your database for anything, you’ll need another database that can get scrubbed by WPLoader. You can use commands similiar to these to create two databases:

  • mysql -u root -ppassword
  • CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
  • CREATE DATABASE wordpress_unit_test DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
  • CREATE USER 'wordpressuser'@'localhost' IDENTIFIED BY 'password';
  • GRANT ALL ON wordpress.* TO 'wordpressuser'@'localhost' IDENTIFIED BY 'password';
  • GRANT ALL ON wordpress_unit_test.* TO 'wordpressuser'@'localhost' IDENTIFIED BY 'password';
  • FLUSH PRIVILEGES;

Codeception uses YML files to handle configuration on a per project and per suite level. A YML file is a formal data structre, similar to a JSON object. You can edit it with your IDE or a text editor. There should be one main YML file in your project’s root directory, codeception.yml. You should have a seperate YML for each suite: (unit.suite.yml, acceptance.suite.yml), in the /tests directory.

You will also have to consider the regular wp-config.php file if you are testing locally [in the root /var/www/html directory on Ubuntu]. This can be a point of confusion, since you have to enter database credentials into the YML files anyway, it might be overlooked that there are a seperate set of credentials in the wp-config.php file. If you are just doing stateful acceptance tests, this doesn’t matter. If you are doing unit tests, or acceptance tests with database snapshots, you’ll have to consider both sources of credentials. When WPWebDriver [i.e. during an acceptance test] accesses the site through http, when you do a cURL, or when you manually use a browser to vist “localhost”, then the wp-config.php will be accesssed, and you’ll have to consider it.

One way to handle the situation, is to put creds for your stateful, and junk databases in the wp-config.php, just comment out one of them:

define('DB_NAME', 'wordpress');
//define('DB_NAME', 'wordpress_unit_test');

WPLoader merely uses the YML file credentials, as it does not route an entire system load through Apache.

It costs next to nothing to deploy a full scale development server in the cloud, so you should NEVER run WPLoader tests on a production server. You are asking for trouble.

Leave a Reply