WPDb and multisite support 01

Where I lay down some ideas for future struggles.

Some measure of support

The WPDb module part of wp-browser deals with WordPress database abstracting the insertion, removal and check of entries in WordPress tables with methods like havePostInDatabase or dontSeeUserInDatabase.
To a measure multisite installations are taken into account with methods like useBlog or useMainBlog but this will only take care of using the right table prefix for non unique WordPress database tables like posts and terms.
Someone writing a test is left to his own devices when trying to set up complex text fixtures involving multisite installations; Codeception eases the struggle with the use of Codeception environments but a database starting dump is required and, in WordPress case, that’s not an easily sharable fixture.


Relevant URLs like home_url and site_url are saved in the database and this means that any operation involving a WordPress managed URL will be unique to the developer local set up.
The goal of this series of iterations on the WPDb module is to make fixtures reliable in specific WordPress applications and have fixtures set up using human readable methods rather than machine readable SQL dump files.
The current version allows to set up the fixture in a CEST type test case using code like this

use Codeception\Module\FunctionalHelper;

class WPDbUserCest {

    public function _before( FunctionalTester $I ) {
        $aboutPageId = $I->havePageInDatabase(['post_title' => 'About']);
        $I->havePostMetaInDatabase($aboutPageId, '_show_edit_to_roles', ['administrator']);

    public function _after( FunctionalTester $I ) {

     * @test
     * it should not see the edit button on the "About" page
    public function it_should_see_the_edit_button_on_the_about_page( FunctionalTester $I ) {
        $I->wantTo('make sure I do not see Edit button as an editor');
        $I->haveUserInDatabase('Luca', 'editor',['user_pass'=>'luca']);
        $I->loginAs('Luca', 'luca');

        $I->doNotSee('Edit', 'button');

The advantage over a SQL dump is readability first and self-contained test fixture on the other.


I’d like to be able to do the same while handling multisite installations and can think of some methods that could support a similar fixture set up mechanism

$I->haveMultisite(true); // `true` for sub-domain, `false` for sub-folders
$I->haveBlog($data); // columns from the `blogs` table
$I->haveManyBlogs($count, $data);

And so on. While I do not have an exact idea of the work involved this seems like a worthy code exploration.