Developing software in the Real World

Testing Slim Framework actions

To test a Slim Framework action, you need a request and a response object and mock whatever is in the action. This is one way to do this.

Consider this simple echo action that returns the query parameters to you as a JSON encoded string:

This is one of those useful API endpoints that your users can use to check that everything is working as expected.

The action under test

The code for this endpoint is a class called EchoAction which looks like this:

and it is registered with the Slim App like so:

Testing

Testing it isn't too complex as there are no dependencies on the EchoAction class itself, so we just have instantiate the class, invoke it and write an test.

For a URL of the form /echo?foo=bar, the core test code is:

Creating the request and response

Creating the $response is easy as the constructor parameters all have defaults:

The $request is a little more complex as it's constructor signature looks like this:

However, Slim actually creates a Slim\Http\Request using the static createFromEnvironment() factory method, which takes a Slim\Http\Environment instance. Roughly, it does this:

Setting up a $_SERVER array with the relevant elements can be a little tiresome in testing though. Fortunately, Josh needed to test Slim itself, so the Environment object has a handy static method called mock() that does this for us.

We use it like this:

As you can see, mock() takes an array which contains $_SERVER keys that we wish to set up for our particular test. Usually we set the REQUEST_METHOD, REQUEST_URI and, if we need it, QUERY_STRING. We need QUERY_STRING as this is the key in $_SERVER that Request uses to determine the query parameters for the request.

Putting it all together

Hence, our completed test looks like this:

All in all, it's not too complicated to test a Slim action and Environment::mock() makes it easy to set up particular test cases.

4 thoughts on “Testing Slim Framework actions

  1. Hi Rob, thank you for taking the time and writing about this subject. Nevertheless, I have a small doubt. What if my middleware, or my action class has a dependency? Since the application singleton has gone, how can I access the DI container in the test to inject the dependency, or dependencies?

    You instantiate EchoAction without problems in this case, but only because there are no dependencies. I suppose I could instantiate my dependency, and pass it to EchoAction, but what if my dependency has a dependency?

    I have registered everything in the container, now I need a way to access it in the test! Again, thanks for the hard work and dedication.

  2. Hi again Rob, I have another doubt. How about testing just one Middleware? I have 4 very simple middlewares, one of them being CorsMiddleware, and another one CsrfMiddleware.

    The signature is the common one: public function __invoke(Request $request, Response $response, $next). I have registered it in the DI container, and also added it to the stack with $app->add(\app\middleware\CorsMiddleware::class);

    The question is: if I don't wanna test the other two, and this is the first one being executed, how can I stop the $response = $next($request, $response) from being called? I mean, can I mock the next callable (CsrfMiddleware in this case) and set expectations about __invoke?

    BTW, thanks for the super quick response, I think you were bored or something.

Thoughts? Leave a reply

Your email address will not be published. Required fields are marked *