0

I'm thinking about the way that I can test this class, its interface only exposes two methods, add_property and remove_property which just wrap the Recurly API.

class SubscriptionManager

  def initialize(account_code)
    @account_code = account_code
  end

  def add_property
    subscription.update_attributes subscription_add_ons: [{ add_on_code: 'property', quantity: property_count + 1 }]
  end

  def remove_property
    subscription.update_attributes subscription_add_ons: [{ add_on_code: 'property', quantity: property_count - 1 }]
  end

  private

  def property_count
    subscription.add_ons.first[:quantity]
  end

  def subscription
     @subscription ||= Recurly::Subscription.find(@account_code)
  end
end

Here is the outlines of the test that I am trying to write, but my goal here is not to hit the API since the Recurly gem provides a nice wrapper with its own set of tests. However, I'm starting think I can only do this by hitting the API. Anyone have any ideas?

describe SubscriptionManager do
  subject  { SubscriptionManager.new('1') }

  before do
    subscription = mock 'Subscription'
    Recurly::Subscription.stub(:find).with('1').and_return subscription
  end

  describe 'add_property' do
    it 'increases the quantity of the property add on' do

    end
  end

  describe 'remove_property' do

    it 'decreases the quanity of the property add on' do

    end
  end
end
TheDelChop
  • 7,938
  • 4
  • 48
  • 70

1 Answers1

0

Check out the VCR gem - it allows API testing without hitting the API once set up.

nmott
  • 9,454
  • 3
  • 45
  • 34
  • 1
    THis is not what I meant, I want to avoid hitting the model all together. The API is well tested, I don't need to hit it, I can accurately stub it and understand what the responses should be. – TheDelChop Feb 20 '12 at 23:53
  • @TheDelChop - Unfortunately, stubbing the responses and testing your code that way is what you will have to do in testing an API wrapper – dennismonsewicz Feb 11 '13 at 21:48