Back to the origin of the core suite installation process.
A WPLoader test flow
the WPLoader
module part of the wp-browser suite wraps the WordPress PhpUnit test suite in a way that will allow an easier interaction with it.
I’ve struggled quite some time to understand what’s happening under the hood of the PhpUnit-powered suite and appreciate what’s happening behind the lines of a test case like this:
<?php
class APluginTest extends \Codeception\TestCase\WPTestCase
{
public function setUp()
{
// before
parent::setUp();
// your set up methods here
}
public function tearDown()
{
// your tear down methods here
// then
parent::tearDown();
}
/**
* @test
* it should be installed and active
*/
public function it_should_be_installed_and_active()
{
$this->assertEquals('yes', get_option('acme-plugin-is-installed'));
}
public function test_me_1(){
// ok!
}
public function test_me_2(){
// ok!
}
}
WPBrowser readme document, echoing the Core test suite, states about the WPLoader
module:
Since this module takes charge of setting up and cleaning the database used for the tests point it to a database that does not contain sensible data!
Why is that? In short this is what happens when I run a test using the WPLoader
module (e.g codecept run integration
):
- Codeception loads the
WPLoader
module - during initialization the module reads the configuration parameters and defines some constants
- some constants and globals are set and passed to an installation script
- during the installation the script
DROP
s all the tables from the database - WordPress is installed from scratch
- plugins that require activation are activated and eventual extra tables are created by the plugins
All this happens once before any test ran; in a way this phase is similar to PhpUnit test setUpBeforClass
method.
After this the following will happen for every test method:
- any left over from previous tests is cleared eliminating any post, user, term, option and so on
- WordPress globals are reset
$wpdb
instance is instructed to run any successive call in a transaction
at this point the test code I wrote runs. This could be the code from the example above:
$this->assertEquals('yes', get_option('acme-plugin-is-installed'));
Finally:
$wpdb
rolls back any instance- some more cleanup happens
Isolating the installation
The Core team did run the installation script in a separate process since the beginning.
Me being one to re-invent the wheel I have instead ran the installation script in the same variable scope as the tests.
While I was able to get around hiccups and bumps on the road more custom and elaborate installations would not work in such a predicament.
That’s why, triggered by Jonathan Brinley’s suggestion, I’ve been working to be able to run the installation in a separate process again without losing the sugar methods the WPLoader
module granted until now.
Next
I will switch the default installation process from the currently same variable scope one to the isolated one and see how it works.