Developing applications that engage with external APIs can be a tricky business, especially when it comes to testing. Making real HTTP requests during tests can be a slow process and may introduce a whole world of unpredictability. The external API might be down, or it might send back unexpected responses, messing with the reliability of your tests. This is where mocking HTTP requests becomes a lifesaver, particularly in the Ruby ecosystem. Enter the WebMock gem, a true hero in the world of testing.

Mocking HTTP requests can solve a bunch of issues, making testing better and faster. Real HTTP requests can drag down your test suite’s speed, dragging it like a slowpoke turtle. Mocking can shave off those precious seconds by zipping through without making real network calls. Plus, external APIs are like the wild west – anything can happen. One minute they’re up, the next, they’re down or spewing out different responses. Mocking ensures consistency, meaning your tests will always get the same response, making them as reliable as your trusty old car. Not to mention, with mocking, you gain total control over the responses your application will deal with, allowing you to test edge cases and error scenarios you wouldn’t want popping up uninvited.

For Ruby developers, WebMock is a fantastic tool for mocking HTTP requests. You can set it up easily by adding it to your Gemfile and running the bundle install command.

# Gemfile
group :test do
  gem 'webmock'
  gem 'rspec'
end

Once it’s in, you’ll want to require WebMock in your test setup. If RSpec is your testing tool of choice, you’d typically throw this into your spec_helper.rb file.

# spec/spec_helper.rb
require 'webmock/rspec'
WebMock.disable_net_connect!(allow_localhost: true)

That last line, WebMock.disable_net_connect!(allow_localhost: true), ensures that no real HTTP requests sneak through during your tests, making sure all requests get stubbed like a well-organized library.

So, stubbing requests with WebMock is pretty straightforward. Imagine you’re trying to stub a GET request to an external API:

describe '.get_balance' do
  context 'valid request' do
    before do
      @stub = stub_request(:get, "https://api.xendit.co/balance")
        .to_return(status: 200, body: '{"balance": 1241231}', headers: {})
    end

    it 'should return the current balance of the merchant account' do
      api_key = ENV['XENDIT_API_KEY']
      client = Client.new(api_key: api_key)
      result = client.get_cash_balance
      expect(result.balance).to eq 1241231
      expect(result.balance_cents).to eq 124123100
      expect(@stub).to have_been_requested
    end
  end
end

In this setup, stub_request(:get, "https://api.xendit.co/balance") is setting up a mock for a GET request to that URL. The to_return bit defines what response should come back when this request pings. The test then checks to make sure it gets the expected response and confirms that the request was made.

One really cool feature of WebMock is verifying just how many times a request was made. This is super useful if you need to be sure a function is firing off the right number of requests to an API endpoint.

expect(@stub).to have_been_requested
expect(@stub).to have_been_requested.times(3)
expect(@stub).to_not have_been_requested

These lines will check if the stubbed request was made at all, if it was made a certain number of times, or check to ensure it was never made.

Now, hand-writing stubs for every single API interaction can be a drag. This is where the VCR gem rocks up to save the day. VCR records real API interactions once, then replays them in future test runs. No more manual stubbing; it’s like hitting the easy button.

To get in on the VCR action with WebMock, first add the gems to your Gemfile and configure them in your test setup.

# Gemfile
group :test do
  gem 'webmock'
  gem 'vcr'
  gem 'rspec'
end

Next up, drop some configuration into your spec_helper.rb file:

# spec/spec_helper.rb
require 'webmock/rspec'
require 'vcr'

VCR.configure do |config|
  config.cassette_library_dir = "spec/fixtures/cassettes"
  config.hook_into :webmock
  config.configure_rspec_metadata!
end

WebMock.disable_net_connect!(allow_localhost: true)

With this setup, you can use :vcr metadata in your RSpec tests to enable VCR for recording and replaying interactions.

describe 'ServiceApi' do
  it 'get a post', :vcr do
    response = Net::HTTP.get('jsonplaceholder.typicode.com', '/posts/1')
    expect(response.code).to eq '200'
  end
end

When this test runs, VCR records the API interaction and stores it. Next time, that recorded interaction gets played back, sparing you another call to the real API.

For all their awesomeness, WebMock and VCR do come with some challenges. Writing mocks, especially for complex APIs, can be time-consuming but pays off by speeding up and solidifying your tests. Maintaining the mocks as your app evolves can be a hassle, but VCR helps by auto-recording and updating interactions. And using real responses whenever possible ensures your mocks stay accurate and fresh.

Harnessing the power of WebMock and VCR, you can craft robust, speedy, and reliable tests for your Ruby apps. This approach saves you from the headache of making real API calls during testing, giving you more time to focus on building amazing applications.