CODEWITHSUNDEEP
ruby-on-railsrspecoauth-2.0doorkeeper
idrysdale
idrysdale

Reputation: 1551

Stubbing out Doorkeep Token using rspec_api_documentation

I'm building an API in Rails 4 using rspec_api_documentation and have been really impressed. Having opted to use DoorKeeper to secure my endpoints, I'm successfully able to test this all from the console, and got it working.

Where I am having difficulty now is how to spec it out, and stub the token.

DoorKeeper's documentation suggests using the following:

describe Api::V1::ProfilesController do
  describe 'GET #index' do
    let(:token) { stub :accessible? => true }

    before do
      controller.stub(:doorkeeper_token) { token }
    end

    it 'responds with 200' do
      get :index, :format => :json
      response.status.should eq(200)
    end
  end
end

However, I've written an acceptance test in line with rspec_api_documentation. This is the projects_spec.rb that I've written:

require 'spec_helper'
require 'rspec_api_documentation/dsl'

resource "Projects" do
  header "Accept", "application/json"
  header "Content-Type", "application/json"

  let(:token) { stub :accessible? => true }

  before do
    controller.stub(:doorkeeper_token) { token }
  end

  get "/api/v1/group_runs" do
    parameter :page, "Current page of projects"

    example_request "Getting a list of projects" do
      status.should == 200
    end
  end
end

When I run the test I get the following:

undefined local variable or method `controller' for #<RSpec::Core

I suspect this is because it's not explicitly a controller spec, but as I said, I'd rather stick to this rspec_api_documentation way of testing my API.

Surely someone has had to do this? Is there another way I could be stubbing the token?

Thanks in advance.

Upvotes: 3

Views: 1982

Answers (2)

gillien
gillien

Reputation: 412

I had the same problem and I created manually the access token with a specified token. By doing that, I was then able to use my defined token in the Authorization header :

resource "Projects" do
  let(:oauth_app) { 
    Doorkeeper::Application.create!(
      name: "My Application", 
      redirect_uri: "urn:ietf:wg:oauth:2.0:oob" 
    ) 
  }
  let(:access_token)  { Doorkeeper::AccessToken.create!(application: oauth_app) }
  let(:authorization) { "Bearer #{access_token.token}" }

  header 'Authorization', :authorization

  get "/api/v1/group_runs" do
    example_request "Getting a list of projects" do
      status.should == 200
    end
  end
end

Upvotes: 3

oestrich
oestrich

Reputation: 51

I wouldn't recommend stubbing out DoorKeeper in an rspec_api_documentation acceptance test. One of the benefits of RAD is seeing all of the headers in the examples that it generates. If you're stubbing out OAuth2, then people reading the documentation won't see any of the OAuth2 headers while they're trying to make a client.

I'm also not sure it's possible to do this nicely. RAD is very similar to a Capybara feature test and a quick search makes it seem difficult to do.

RAD has an OAuth2MacClient which you can possibly use, here.

require 'spec_helper'

resource "Projects" do
  let(:client) { RspecApiDocumentation::OAuth2MACClient.new(self) }

  get "/api/v1/group_runs" do
    example_request "Getting a list of projects" do
      status.should == 200
    end
  end
end

Upvotes: 2

Related Questions