Providing fixtures in PHPUnit tests

Providing pre-conditions in PHPUnit tests.

The problem

Most of my development happens in a WordPress environment and this means that I can mock objects and dependencies to a point when setting up the fixtures my test will happen in.
Most of the time I’m setting up globally defined objects and variables and return values in methods.
The thing can get tedious and while I’m harnessing function-mocker power to the last drop to simplify my tests I still have to walk that road.

Data providing closures

The PHPUnit test suite implements ways to provide a test method with test data: data providers.
As the name and the examples imply data will be provided to test methods.
The nature of that data, though, is up to the developer writing the test methods.
When the dependencies of a subject under test are represented by object instances alone then mocking them is enough to set up the fixture for the test.
The case below is an example of when that’s not possible without recurring to redundant object wrapping (a way I’ve walked but that’s simply not maintainable in a shared code base):

use tad\FunctionMocker\FunctionMocker as Test; 

class MyTest extends \PHPUnit_Framework_TestCase{

    public function setUp(){

    public function tearDown(){

    public function badContexts() {
        return [
                function () {
                    unset( $_REQUEST[ Register::$query_var ] );
                function () {
                    unset( $_REQUEST['_wpnonce'] );
                function () {
                    Test::replace( 'wp_verify_nonce', false );

     * @test
     * it should not start sync if no context
     * @dataProvider badContexts
    public function it_should_not_schedule_sync_if_no_context( $fixture ) {
        // set up the fixture for the test

        $wp_schedule_single_event = Test::replace( 'wp_schedule_single_event' );



The object method I’m testing is checking the $_REQUEST global for a value and calling a WordPress defined function, wp_verify_nonce, to make sure the context is good and the method should go ahead.
What is happening is that I’ve moved the fixture set up code in closures and am calling them first thing in the test method; otherwise I would have had to write 3 distinct test methods.
This is usually the way I do it and it makes tests very explicit and readable; in this case “bad context” is a definition precise enough to be readable in this context.
Had I had the issue to set up, say, 6 different conditions then I would have probably split the object further.