Command Line WordPress, Node.js, Unit Testing

Dockunit: Containerized Unit Testing Across Any Platform and Programming Language

Problem:

I want my application to work on all the environments I claim to support but I have no way of easily testing updates in each environment.

Bad Solution:

Continuously push to your remote to force Travis CI to test changes in multiple environments.

Good Solution:

Containerized unit testing with Dockunit.

Dockunit is a simple node command that lets you run your test framework of choice across a number of predefined containers. Each container can have it’s own test command and Docker image. It was born out of the need to ensure my PHP applications (WordPress specifically) were compatible with a spectrum of environments. Travis CI dropping support for PHP 5.2 was the final straw so I created this command for myself and decided to make it public.

Install/Usage Instructions for Dockunit

1. Ensure dependencies are met. See requirements on Github.

2. Install Dockunit

npm install -g dockunit

3. Setup project(s) with predefined containers.

To do this create a file called Dockunit.json in the root of any project you want to run Dockunit on. Github contains specific guidelines for how to write Dockunit.json files. Here is an example file for testing a WordPress plugin in PHP 5.2 FPM in WordPress 4.1, PHP 5.5 FPM in WordPress 4.0, and PHP 5.5 for Apache in WordPress 3.9:

{
  "containers": [
    {
      "prettyName": "PHP 5.2 FPM WordPress 4.1",
      "image": "tlovett1/php-5.2-phpunit-3.5",
      "beforeScripts": [
        "service mysql start",
        "bash bin/install-wp-tests.sh wordpress_test root '' localhost 4.1"
      ],
      "testCommand": "phpunit"
    },
    {
      "prettyName": "PHP 5.5 FPM WordPress 4.0",
      "image": "tlovett1/php-fpm-phpunit-wp",
      "beforeScripts": [
        "service mysql start",
        "bash bin/install-wp-tests.sh wordpress_test2 root '' localhost 4.0"
      ],
      "testCommand": "phpunit"
    },
    {
      "prettyName": "PHP 5.5 for Apache WordPress 3.9",
      "image": "tlovett1/php-apache-phpunit-wp",
      "beforeScripts": [
        "service mysql start",
        "bash bin/install-wp-tests.sh wordpress_test3 root '' localhost 3.9"
      ],
      "testCommand": "phpunit"
    }
  ]
}

3. Run Dockunit command.

dockunit

Note: This assumes you have changed directories to your project root. You may need to sudo.

Detailed command usage instructions can be found on Github. Contributions and bug reports are encouraged :).

Standard
Command Line WordPress, Unit Testing, WP API

Using the WordPress JSON REST API in Testing Suites with Travis CI

Problem:

We are writing custom endpoints and routes that extend WP API in a theme or plugin. We want to write tests for this code and run tests in Travis CI. Right now, WP API is not in WordPress core and must be included as a plugin. Therefore, we have a WordPress plugin/theme that depends on another plugin. We want to make sure all our dependencies are installed/included when we bootstrap our testing suite. WP API is not a registered Composer package.

Bad Solution #1:

Complain about WP API not being a registered Composer package. Just joking. The reason behind this is that WP API must remain backwards compatible after being included in WordPress core.

Bad Solution #2:

Include WP API in your theme/plugin as a Git submodule. Not only are Git submodules annoying but this doesn’t even make sense. Git submodules point to a specific commit. We want to just install the latest stable version which isn’t possible using submodules unless we want to manually update our submodule commit hash every time WP API is updated.

Final Solution

We need to manually include WP API in our plugin/theme but we want it up-to-date. We want to pretend WP API is a Composer package. If it’s not already there, create a folder vendor/ in the root of your project. This is the same folder that Composer will store your packages. Add vendor/ to your .gitignore since we don’t need this code in production (assuming you don’t have other packages in vendor that are needed in production).

We can execute bash scripts whenever Composer install/update is called. Let’s write a simple Bash script to clone/update WP API into vendor/. Place this code in bin/install-wp-api.sh:

cloneOutput=$(git clone https://github.com/WP-API/WP-API.git ./vendor/wp-api 2>&1)

if [[ $cloneOutput =~ "destination path './vendor/wp-api' already exists" ]]; then
  cd vendor/wp-api
  git reset --hard &>/dev/null
  git checkout master &>/dev/null
  git reset --hard &>/dev/null
  git pull origin master &>/dev/null
fi

This script will clone WP API, if it doesn’t exist. Otherwise it will checkout the master branch and pull the latest from Github.

Now we need to execute this script. We will use Composer scripts. Here is an example composer.json file:

{
    "name": "tlovett1/package-name",
    "description": "Description of my package.",
    "license": "MIT",
    "authors": [
        {
            "name": "Taylor Lovett",
            "email": "email@email.com"
        }
    ],
    "minimum-stability": "stable",
    "require": {},
    "scripts": {
        "pre-install-cmd": [
            "./bin/install-wp-api.sh"
        ],
        "pre-update-cmd": [
            "./bin/install-wp-api.sh"
        ]
    }
}

composer.json defines your package as a Composer package, registers it’s dependancies, and more. As I mentioned before, we can call scripts as well. We use the pre-install-cmd hook to execute our script every time composer install is called. We use the pre-update-cmd hook to execute our script every time composer update is called. On both of these hooks we are executing our script at ./bin/install-wp-api.sh.

Now we simply add the following to our .travis.yml file:

before_script:
   - composer install

In your test suite bootstrap file, you can insert the following PHP to manually use WP API assuming you are using the WordPress standard unit testing suite:

function _manually_load_plugin() {
	require( dirname( __FILE__ ) . '/../vendor/wp-api/plugin.php' );
}
tests_add_filter( 'muplugins_loaded', '_manually_load_plugin' );

EDIT: Another solution which is easier than this one is using a composer inline package.

Standard
Unit Testing, WordPress Code Techniques, WordPress Core

WP_UnitTestCase: The Hidden API

Background:

Unit testing is the automated testing of units of source code against assumptions. The goal of unit testing is to write test cases with assumptions that test if a unit of code is truly working as intended. If an assumption fails, a potential issue is exposed, and code needs to be revised.

By definition unit tests do not have dependencies on outside systems; in other words only your code (a single unit of code) is being tested. Integration testing works similarly to unit tests but assumptions are tested against systems of code, moving parts, or an entire application. The phrases unit testing and integration testing are often misused to reference one another especially in the context of WordPress. This article will try to stay consistent with WordPress terminology whether correct or not. Personally, in writing tests for my WordPress plugins/themes I write integration tests which I feel are more useful for a number of reasons that are outside of the realm of this article.

PHPUnit is the defacto library used to run unit and integration tests in PHP and thus server-side WordPress. This article assumes you are familiar with basic concepts of unit testing with PHPUnit.

What is WP_UnitTestCase?

WP_UnitTestCase is a PHP class included in the WordPress core development repository. Using SVN, you can check out that repo like so:

svn co http://develop.svn.wordpress.org/trunk/ wordpress-develop

The WordPress core development repository contains the core WordPress unit tests. Cool, huh? You can setup these tests, run them, and even write your own! Let’s poke around a few WordPress core test files. Open up wordpress-develop/tests/phpunit/tests/actions.php.

Normally, PHPUnit tests are structured like so:

class MyTestSuite extends PHPUnit_Framework_TestCase {
  public function setUp() {
    // This code will run before each test!
  }

  public function tearDown() {
    // This code will run after each test
  }

  public function testBasic() {
    $this->assertTrue( true );
  }
}

However, when writing integration tests for WordPress based applications, there exists a cool API we can leverage: WP_UnitTestCase. Remember how I asked you to open the actions.php file? You will see the test class in there extends WP_UnitTestCase. WP_UnitTestCase provides shortcuts for doing a number of tasks when creating your test cases. The first thing you will need to do to use this API is to require the file in your PHPUnit bootstrap file:

require_once( $tests_dir . '/includes/bootstrap.php' );

Of course you will need to setup $tests_dir appropriately. Within the WordPress core development repository, this bootstrap file lives at /tests/phpunit/includes/bootstrap.php. Including this bootstrap file will “bootstrap setup” WordPress, setup some things for unit testing, and include a number of useful things one of which is WP_UnitTestCase. There are other ways you could include WP_UnitTestCase, but this is by far the easiest.

Let’s setup our test class to use WP_UnitTestCase:

class MyTestSuite extends WP_UnitTestCase {
  public function setUp() {
    parent::setUp();
    // This code will run before each test!
  }

  public function tearDown() {
    parent::tearDown();
    // This code will run after each test
  }

  public function testBasic() {
    $this->assertTrue( true );
  }
}

Notice our class is extending WP_UnitTestCase instead of PHPUnit_Framework_TestCase. You can probably guess that WP_UnitTestCase extends PHPUnit_Framework_TestCase so we can use everything in PHPUnit_Framework_TestCase by extending WP_UnitTestCase plus a bunch more. Also notice within setUp() and tearDown() we are calling the same methods in the parent class; this is extremely important to ensure WP_UnitTestCase is working correctly. WP_UnitTestCase::setUp() and  WP_UnitTestCase::tearDown() do a bunch of magic such as cache clean up and global resets.

WP_UnitTestCase has an instance variable named $factory. Before each of your tests is run $factory is set to a newly instantiated object of type WP_UnitTest_Factory. The meat of WP_UnitTestCase is in this $factory variable. Let’s look some cools way that we can use WP_UnitTestCase.

Creating Blogs within a Network

public function testBasic() {
  $blog_id = $this->factory->blog->create();
  $blog_id_array = $this->factory->blog->create_many( 4 );
}

This is extremely useful for writing test cases that make cross-site assumptions. As you can tell $this->factory->blog->create() creates a blog and returns the new blog ID. $this->factory->blog->create_many( 4 ), creates 4 new blogs and returns an array of the ID’s in order.

If multisite is not setup, this factory will not exist! You can ensure WordPress is bootstrapped as multisite by setting the following constant up in your phpunit.xml file:

<const name="WP_TESTS_MULTISITE" value="1" />

Creating Test Posts

public function testBasic() {
  $post_id = $this->factory->post->create();
  $post_id_array = $this->factory->post->create_many( 4 );
}

Many times when I am writing tests I need to bulk create posts. WP_UnitTestCase let’s you accomplish this very easily. You can pass an array of post args (same as wp_insert_post) like so: create( $args ) and create_many( $num, $args ). If no arguments are passed, generic post_title/post_content info is generated. Post args passed to create_many will be applied to every post created.

Creating Test Comments

public function testBasic() {
  $comment_id = $this->factory->comment->create();
  $comment_id_array = $this->factory->comment->create_many( 4 );
}

Again, we can leverage WP_UnitTestCase to bulk create comments. You can see the ways to use the class is very consistent :). Comment args (like wp_insert_comment) can be passed to create() and create_many() in the exact same way as the post factory.

Creating Test Users

public function testBasic() {
  $user_id = $this->factory->user->create( array( 'user_login' => 'test', 'role' => 'administrator' ) );
  $user_id_array = $this->factory->user->create_many( 4 );
}

WP_UnitTestCase allows us to bulk create users as well. User args (same as wp_insert_user) can be passed to create() and create_many() in the same fashion as the post factory.

Creating Test Terms

public function testBasic() {
  $term_id = $this->factory->term->create( array( 'name' => 'Term Name', 'taxonomy' => 'category', 'slug' => 'term-slug' ) );
  $term_id_array = $this->factory->term->create_many( 4, array( 'taxonomy' => 'category' );
}

Creating bulk terms is slightly different from other factories. Create() and create_many() do take arguments the same was as wp_insert_term(). However, we provide ‘taxonomy’ and ‘name’ as a part of the array rather than as separate parameters.

Conclusion

WP_UnitTestCase contains additional factories for categories, tags, networks, and attachments. They work in a similar fashion as the factories above, so I will let you explore these API’s yourself :). WordPress contains a bunch of other useful API’s for building your test suites such as a system for mocking actions and a test case class for AJAX hooks. I plan on outlining those tools and a few others in future blog posts.

Standard