WPLoader separated installation process 00

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 DROPs 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.