Equality

assertEquals()  $expected == $actual?

$this->assertEquals($expected, $actual);

assertSame()  $expected == $actual?

$this->assertSame($expected, $actual);

Verifying contents of things

assertContains () Does $value contain $expected?

$this->assertContains('b', ['a', 'b', 'c']);

assertRegexp() Does $value match the given $regex?

$this->assertRegexp('/^Fo+/', 'Foo Bar');

Negative assertions

For every assertion, there is a positive and negative assertion.

assertEquals () $expected ==$actual?

assertNotEquals () $expected ==$actual?

 

assertContains () $expected ==$actual?

assertNotContains () $expected ==$actual?

 

assertCount () $expected ==$actual?

assertNotCount () $expected ==$actual?

 

assertArrayHasKey () $expected ==$actual?

assertNotArrayHasKey () $expected ==$actual?

 

Do we have at least one match? Everything comes down to true or false. The key to understanding assertions in our tests. Here is an example of a test report:

PHPUnit 7.5.1 by Sebastian Bergmann and contributors.

...............................................  47 / 511 ( 9%)

...............................................  94 / 511 ( 18%)

...................................SSSS........ 141 / 511 ( 27%)

............................................... 188 / 511 ( 36%)

............................................... 235 / 511 ( 45%)

............................................... 282 / 511 ( 55%)

............................................... 329 / 511 ( 64%)

............................................... 376 / 511 ( 73%)

............................................... 423 / 511 ( 82%)

............................................... 470 / 511 ( 91%)

.........................................       511 / 511 (100%)

 

Time: 1.13 minutes, Memory: 42.00MB

 

OK, but incomplete, skipped, or risky tests!

Tests: 511, Assertions: 1085, Skipped: 4.

 

PHPUnit 7.5.1 by Sebastian Bergmann and contributors.

 

.......F........                                 16/16 (100%)

 

Time: 7.15 seconds, Memory: 14.00MB

 

There was 1 failure:

 

1) Tests\CoffeeTest::test_get_good_coffee

Failed asserting that two strings are identical.

--- Expected

+++ Actual

@@ @@

-'great, well-balanced coffee'

+'Starbucks'

 

/my-plugin/tests/test-coffee.php:14

 

FAILURES!

Tests: 16, Assertions: 19, Failures: 1.

It ran through over 1K test in under a minute. If you were to do this manually it would take days instead of minutes. 

Test Doubles

As we test things, sometimes we want to get things out of the way in our code. This is where test doubles come into play. The general idea is to remove any variables in our code and give ourselves test versions to replace actual systems. Always returning known values and ensuring systems behave a certain way. When dealing with test doubles, a popular library for creating test doubles is Mockery.

public function test_handles_empty_order_list() {

    $api = Mockery::mock( Api::class )->makePartial();

    $api->shouldReceive( 'get_all_orders' )

        ->once()

        ->andReturn( [] );

    $this->assertEmpty( $api->get_recent_orders() );

}

There’s also the PHPUnit Markup assertions, powered by DOMDocument. Lets use DOMDocuments to make a DOM query.

function test_button_contains_active_state() {

    $output = some_function();

    $this->assertContainsSelector('.button.active', $output);

}

WP Core Test Suite

This is what WP core itself uses to ensure all the PHP in WP is behaving the way we expect it to. If we want to use the core test suite, you can run $ wp scaffold plugin-tests my-plugin to generate test scaffolding via WP-CLI. Get the test suite out of the box.

We want to make sure certain things happen before every test method. You don’t have to write it every time, only once.

We have the concept of groups where we run tests of a similar nature across suites and classes. I can just run the following code.

/**

 * @group Posts

 * @group PostMeta

 */

public function test_includes_private_posts()

{

    // ...

}

$ phpunit --group=Posts

This comes in handy when you have a large test suite and want to make sure related things aren’t going to break.

Data Providers

Often in our testing you can have the same test but different data. For this, we have a nice tool called data providers. You can run through them without having to paste the same method over and over again. So we specify a data provider for it. If you’re working with simple data types like strings and integers. You can choose to define just one method for example:

/**

 * @dataProvider my_data_provider()

 */

public function test_my_function( $expected, $value ) {

    $this->assertEquals( $expected, my_function( $value ) );

}

 

public function my_data_provider() {

    return [

        'Description of case 1' => ['foo', 'bar'],

        'Description of case 2' => ['bar', 'baz'],

    ];

}

/**

 * @testWith ["foo", "bar"]

 *           ["bar", "baz"]

 */

public function test_my_function( $expected, $value ) {

    $this->assertEquals( $expected, my_function( $value ) );

}

You can even generate dummy data with factories tests. You can generate users, posts and more – for testing purposes.

// Create the post and retrieve its ID.

$post_id = $this->factory->post->create();

 

// Create and retrieve the new post.

$post = $this->factory->post->create_and_get();

 

// Override default parameters.

$post = $this->factory->post->create_and_get( [

    'post_title'  => 'My Test Post',

    'post_author' => $author_id,

] );

 

// Create multiple instances.

$posts = $this->factory->post->create_many( 5, [

    'post_author' => $author_id,

] );

Checking for WP_ERRORS

Was the response an instance of WP_Error? Coming back to the search for truth – Is truth a WP_Error? As we write our code, there’s a pattern for how this should be arranged to set up the scenario.

public function test_function_can_return_wp_error() {

    $response = myplugin_function();

 

    $this->assertWPError($response);

}

Next we execute the code, and finally we make assertions around it – in other words, verify that things happened as you expected.

Testing Permissions

public function test_non_admins_cannot_clear_cache() {

    // Arrange

    $user_id = $this->factory->user->create( [

        'role' => 'author',

    ] );

 

    wp_set_current_user( $user_id );

 

    // Act

    $response = myplugin_clear_cache();

 

    // Assert

    $this->assertWPError($response);

    $this->assertSame(403, $response->get_error_code());

}

Registering a custom post type

public function test_book_cpt_is_registered() {

    myplugin_register_post_types();

 

    $post_type = get_post_type_object( 'book' );

 

    // Verify the post type is registered along with key properties.

    $this->assertNotNull( $post_type );

    $this->assertTrue( $post_type->public );

    $this->assertFalse( $post_type->hierarchical );

}

Testing Hooks

public function test_function_does_action() {

    myplugin_function();

 

    $this->assertSame( 1, did_action( 'myplugin_action' ) );

}

public function test_function_does_action() {

    $called = false;

 

    // Register a callback to validate arguments.

    add_action( 'myplugin_action', function () use (&$called) {

 

        // Only return true if validations passed.

        $called = true;

    } );

 

    myplugin_function();

 

    $this->assertTrue( $called );

}

Testing Output

public function test_shortcode_output() {

    ob_start();

    do_shortcode( '[recent-posts title="Latest Posts"]' );

    $output = ob_get_clean();

 

    $this->assertContains( '<h2>Latest Posts</h2>', $output );

}

public function test_shortcode_output() {

    $this->expectOutput( '<h2>Latest Posts</h2>' );

 

    do_shortcode( '[recent-posts title="Latest Posts"]' );

}

Stubbing HTTP Requests

add_filter( 'pre_http_request', function () {

    return [

        'headers'  => [],

        'body'     => '',

        'response' => [

            'code'    => 200,

            'message' => 'OK',

        ],

        'cookies'  => [],

        'filename' => '',

    ];

} );

Basic Automated Testing Workflow

Steve explains the basic idea behind TDD – test driven development.

1. Write a (failing) test to describe the functionality/behavior. You’re describing how it should work. This can be called ‘red’ – there is a broken code.
2. Write the code necessary to make the test pass. All we have to do is get the test to pass. This can be known as green – the code that works.
3. Refactor, rinse, & repeat. Now we can go back and refine the code.

Automation is the way forward and one that strongly resonates with Plesk’s values and beliefs. You can find the slide deck from the talk here. Thanks Steve for sharing your expertise on automated testing!