Going on in my project of integrating WordPress automated testing with Codeception I’ve moved the core files of the suite from its own folder to the one storing my tests; the idea is to simulate what could become an automated Codeception testing setup and mimic that before committing to any module/extension development. Sorta a “make it work on paper first” approach.
Bare bones
Just after the checkout WordPress automated testing suite will come with
- a fully functional, latest version WordPress installation
- a config file dedicated to the test (
wp-tests-config.php) - WordPress team tests
- PHPUnit configuration files
- WordPress specific test cases and mock objects
a peek to it on svn will make it clearer.
Of all the above I really need just the second one, the wp-tests-config.php file, and the last.
For a test to be of any relevance the WordPress installation to test will be the one the site/theme/plugin is being developed for, the tests I will add (trusting WordPress team will make an excellent job), PHPUnit will deal with Codeception and test cases and mock objects I will reuse. With this objective I’ve moved some of the contents of the folder I had checked out the SVN repository into to the wordpress test suite I had previously created and ended up with a file tree like
tests
| wordpress
| | includes // same as original
| | | bootstrap.php // same as original
| | _bootstrap.php //Codeception creation
| | WordpressTester.php //Codeception creation
| | wp-tests-config.php //same as original
| | FirstTest.php //my creation
What the original phpunit.xml.dist file did was simply loading in the bootstrap and setting some PHPUnit related values; that duty is now taken by Codeception created _bootstrap.php file
<?php
// Here you can initialize variables that will be available to your tests
$wpIncludesPath = dirname(__FILE__) . '/includes';
$bootstrapFile = "$wpIncludesPath/bootstrap.php";
include_once $bootstrapFile;
that will take care of doing just that. WordPress tests very own original bootstrap.php file will take care of loading the wp-tests-config.php file and load WordPress.
The last piece of the puzzle lies in pointing the wp-tests-config.php file to load my WordPress installation of choice and that I will do that modifying the first line of the file (in my current set up WordPress is in a parent folder of the plugin under development)
<?php
/* Path to the WordPress codebase you'd like to test. Add a backslash in the end. */
$wpPath = dirname(dirname(dirname(dirname(dirname(dirname(__FILE__))))));
define('ABSPATH', $wpPath . '/');
// Test with multisite enabled.
...
Ready to roll
Now that the wires are connected I should be able to run my FirstTest again
<?php
class FirstTest extends \PHPUnit_Framework_TestCase
{
/**
* @test
* it should strip all tags
*/
public function it_should_strip_all_tags()
{
$in = '<p>some</p>';
$expected = 'some';
$this->assertEquals($expected, wp_strip_all_tags($in));
}
/**
* @test
* it should add and get an option
*/
public function it_should_add_and_get_an_option()
{
add_option('someOption', 'foo');
$this->assertEquals('foo', get_option('someOption'));
}
}
running, at the command line
phpunit --color --bootstrap tests/wordpress/_bootstrap.php tests/wordpress/FirstTest.php
will result in a passed and in a failed test. 
Thou shall use the proper test case
Simply changing the first line of the test above to use the WP_UnitTestCase will fix the issue
<?php
class FirstTest extends \WP_UnitTestCase
{
taking care of proper database handling. 
Running the test in Codeception like this
codecept run wordpress
will instead result in a message about the missing WP_UnitTestCase class.
What’s happening to bootstraps?
Shouldn’t WordPress test original bootstrap take care of including the WP_UnitTestCase class? It does in PHPUnit but not in Codeception.
After a quick search it seems to be a Codeception issue that’s fixed “manually” loading the suite bootstrap file in the tests case like
<?php
require_once dirname(__FILE__) . '/_bootstrap.php';
class FirstTest extends \WP_UnitTestCase
{
...
and running codeception again will result in green lights. 
Next
I will leave bug resolution to developers better than me and will move into the first attempt of a Codeception integration of the suite.