Testing Custom League OAuth2 Client Providers

Most of this is pretty routine. Implement some getters that are used in a few template methods. Most of those getters are public and easy to test, but a few of the required methods deal with HTTP responses. I was a bit stuck on how to test them. Which brings us to this post!

Under the hood, league/oauth2-client uses Guzzle and Guzzle has some tooling for testing. Testing a custom OAuth 2 provider is about combining the two.

Example: Testing an Access Token Response

In this example the custom provider create a custom access token class. It would be good to make sure that createAccessToken is invoked correctly from the public getAccessToken method.

To test this we’ll set up a Guzzle MockHandler and use it to back a guzzle client. MockHandler is a stub implementation of Guzzle’s usual handler. It returns pre-programmed responses. An OAuth 2 server response to an access token request with a JSON body with a few keys (access_token and expires_in for example).

Should you wish to inspect the requests that were make, Guzzle provides a history middleware. I don’t think this is necessary however. It’s the responsiblity of the league/oauth2-client package to verify that the outgoing requests are correct. Most custom providers only need to worry that they are correctly dealing with responses.

A similar strategy here can be used to verify the other methods that deal with response (checkResponse and createResourceOwner for example.

Why Not Just Mock/Spy a HTTP Client?

I try really hard to avoid mocking code I don’t own. By using Guzzle’s Mock handler I can ensure that I’m using guzzle (via the custom provider) correctly. This is someone of a personal choice. I don’t think mocking an http client or event mocking part of the provider is necessarily bad. But using Guzzle’s built in testing facilities made the most sense to me.

That said, this method will break should league/oauth2-client ever change its underlying http client. So would mocking the http client directly.