Slim Unit Testing Example

Integration and unit testing a Slim PHP application

This is a sample application to show an approach to integration and unit testing a Slim application. To skip to the heart of this, go check out the testing bootstrap. It sets a mock environment and provides some helper methods for testing Slim routes.

About

Slim is a great PHP framework with a small footprint and everything you need to build fast applications. I've found it particularly well suited to delivering data to BackboneJS applications.

However, I haven't found a great deal of information about integration and unit testing with Slim, and have developed my own approach. I've refactored and introduced it into this sample application. I hope it will help others on their path to using this great framework.

This application demonstrates some techniques for integration and unit testing. With this approach, you'll be able to test your application without the need of Curl, webservers, or anything other than PHPUnit installed on your system. This makes it easy to test your entire app in an automated way with TravisCI. Check out the .travis.yml file in this project for an example.

Example

Here's a test for a very simple endpoint that returns the version from the application config. We're asserting that Slim responded with a 200 and that the version matches what we expect.

class VersionTest extends LocalWebTestCase {
    public function testVersion() {
        $this->client->get('/version');
        $this->assertEquals(200, $this->client->response->status());
        $this->assertEquals($this->app->config('version'), $this->client->response->body());
    }
}

Installation

Clone the repository and then run composer install and then phpunit. This application assumes that you have phpunit installed globally on your system. This application can be run as a functioning website. You can you use the sample apache config file in the build/ folder, or use the native php webserver. To use the php webserver, run php -S localhost:8080 -t public/ from the project root and open your browser to http://localhost:8080

Concepts

The public/index.php file serves as the application entry point. This file initializes a Slim $app with production configuration, includes the routes file from app/app.php and then runs the app with $app->run();. This allows us to keep our application separate from the index, and gives us an opportunity to include our app/app.php file in a different context.

When phpunit runs, it looks for the phpunit.xml file in our root. This file specifies a testing bootstrap file. PHPUnit includes testing/bootstrap.php. This file creates an $app, just like in build/index.php, but it uses testing configuration. The bootstrap keeps a reference to $app for the testing framework, and then provides several helper methods for GET, POST, PUT, PATCH, HEAD, and DELETE.

With these methods, you can run tests on Slim routes without a webserver. The tests run entirely within a mock environment and will be fast and efficient.

Unit Testing vs. Integration Testing

Unit tests should test an individual part of code. The system under test should be as small as possible. You would unit test an individual method. Integration testing exercises an entire system. Most of this example is about integration testing. We are running tests that work Slim from initial instantiation to the final delivery of data. With integration tests, we're treating the entire application as a unit, setting up a particular initial environment and then executing the run() command and finally inspecting the results to ensure that they match our expectations.

Mocking with Slim

See the ZenTest for an example of mocking with Slim dependency injection. In this test we mock a Curl wrapper class from Shuber. This allows us to substitute responses and exercise the parts of our application that we feel need testing. It also allows us to run these unit tests on systems that don't have the curl extension installed. We're totally isolated from that dependency while this running test.

The FileStoreTest uses a mock for the authentication class. Notice that the file store route doesn't use that class directly, but instead it is used by the application authenticator method. We're using the app dependency injection container to swap out the real object for a mock version. This approach allows us to control authentication results from within our test harness.

You can read more about dependency injection in the SlimDocs on DI, and more about mock objects in the PHPUnit docs.

Site Tooling

I'd like to give a nod to Pake. It's a flexible and powerful build tool written in PHP. If you've got lots of JavaScript, I might recommend Grunt or Gulp. However, for APIs and other sites that need a build system - I highly recommend Pake. It's got enough tools to handle SSH deployments and other sophisticated build steps. In this project, it's used to setup the dev web server and handle some code sniffs. With the Pake CLI tool you don't have to install it globally. I think it's a compelling and overlooked tool. Go see it!

Contributing

Open an issue for questions, comments, or suggestions. Pull requests are welcome, please format the code to PSR-2 standards and include an explanation of the benefits.

Contributors

Author	Commits
Craig Davis	63
Jeremy Kendall	3
guillermo-fisher	1

Changelog

• 0.1.1 Update Readme and remove echo and include in place of a proper rendering.
• 0.1.0 Backwards compatibility breaking - Reorder the parameters on the get(), post() and http testing methods to be in the new order of $this->$method($path, $formVars, $optionalHeaders);. This makes the testing a little more terse, and clears up any confusion with improved parameter names.
• 0.0.9 Bug fix for issue 4, with thanks to origal for his work in solving a problem with get parameters.

Thanks

Thanks must be given to Nicholas Humfrey for his work in this integration testing harness.