Testing Ueberauth adapters

I’ve implemented a Ueberauth adapter, and now I should write the tests.
I’m finding it surprisingly difficult, and I’d like to ask for suggestions.
What I started doing is implementing something that mocks the OAuth2.Client interface (get_token! and so on) but I must say my tests are worthless.
For example, this is one of the most complex tests in when dealing with oauth:

  def get_token!(params \\ [], options \\ []) do
    headers        = Keyword.get(options, :headers, [])
    options        = Keyword.get(options, :options, [])
    client_options = Keyword.get(options, :client_options, [])
    client         = @oauth_client.get_token!(client(client_options), params, headers, options)

I feel like there’s not much to test here, what can eventually go wrong? All the function calls are explicit, and most complexity is in @oauth_client, which I dumbed down because I’m not testing the oauth client, but only my adapter.
To my surprise, none of the ueberauth adapters has a single test, which is weird and leaves me wondering why the author/s thought that code wasn’t worth of any test (example: https://github.com/ueberauth/ueberauth_github/)
Every suggestion is very welcome, right now my guts feeling is that I’m spending lots of time doing things that are simply not worthy, this thing basically calls external libraries and not much more, but as I think it’s quite common to use ueberauth for authenticating users, I ask if anybody else has the same feeling and can eventually share an example of an adapter that went a little bit after the assert (1 + 1 == 2) :slight_smile:

Thanks in advance,

1 Like

Whenever I am not sure how to start to test and especially when I implemented before I started testing, then I just throw some derivate of quickcheck (QC) at the function and wait what happens.

When QC finds something I use that data for a unit test.

1 Like

I think it’s worth writing tests for an Ueberauth adapter. In fact, the simplicity of it should be an encouragement!

Mocking an OAuth2 client is a perfect opportunity to practice the Mocks and explicit contracts technique that Jose has described.

For testing the strategy you can use Plug.Test to make sure your callbacks are returning the connection you expect.

If you look at the List of Strategies on their wiki you can find some user contributed packages that have tests. These are the ones I found (including one I wrote):

1 Like

Thanks a lot for the tip, I’m looking at your adapter and it’s the only one I really like, because it doesn’t use real requests from the main service, like for example the VK one does.
I guess I’m just being dumb but I don’t really understand how you’re mocking the service and where. I’m doing something very close to what you’re doing and my requests hit the production server. Even the first test in the example I’m going to post, which can’t get any easier, is using the response from the real production server, but if I run your tests I see there are no HTTP calls (at least I guess, it runs all tests in under a second). Can you help me?


I don’t really understand how you’re mocking the service and where

The ueberauth_flickr package is built on top of a Flickr client library called Flickrex that I also wrote. Flickrex has a configurable OAuth module and a Mock version of it which ueberauth_flickr can direct it to use when testing.

If I hadn’t written both packages I likely would not have coupled the testing config like this. I either would have made ueberauth_flickr mock the entire Flickrex client, or else copied in all the OAuth code (and Mock) and dropped the dependency on :flickrex.

You’re right that with mocking the OAuth client, there are no network requests and the tests are very fast.

1 Like