从您的应用发送真实的HTTP请求可能会有一些严重的缺点：

• 由于连接问题而导致的抖动测试。
• 测试套件速度显著降低。
• 在第三方站点上达到API速率限制
• 服务可能尚不存在（仅存在其文档）。
• 非确定性响应可能导致抖动测试。
• API可能不提供沙箱或测试模式。

您还需要权衡每个应用的清晰边界与测试敏锐度。正确尊重应用边界意味着您只测试应用是否按照API指定的方式与协作者通信，并排除实际通信。
当然，缺点是当涉及到测试的敏锐度时，stubbing总是要付出代价的。你可能会错过API不像文档所描述的那样工作的bug，或者你只是在测试错误的东西。
例如，Webmock可以让你完全去掉HTTP层。你可以设置外部调用的期望值，并模拟返回值。
第一个

VCR另一方面是一种中间道路，它允许您执行真实的HTTP请求，并将其记录到YML文件中，然后回放结果。随后的运行速度更快且具有确定性。VCR比设置模拟响应轻松得多，但是您仍然需要处理设置初始状态和清除测试对外部服务的任何副作用。

VCR.use_cassette("synopsis") do
  response = Net::HTTP.get_response(URI('http://example.com'))
  expect(response.body).to match("Example domain")
end

这是一个从使用Flickr API的真实的应用程序中提取的示例：

RSpec.feature 'Importing photosets from flickr' do

  include JavascriptTestHelpers

  let(:user) { create(:admin, flickr_uid: 'xxx') }

  before { login_as user }

  let(:visit_new_photosets_path) do
    VCR.use_cassette('photosets_import') { visit new_photoset_path }
  end

  scenario 'When I create a photoset it should have the correct attributes', js: true do
    visit_new_photosets_path
    VCR.use_cassette('create_a_photoset') do
      click_button('Create Photoset', match: :first)
      wait_for_ajax
    end
    find('.photoset', match: :first).click
    expect(page).to have_content "Showcase"
    expect(page).to have_content "Like a greatest hits collection, but with snow."
    expect(page).to have_selector '.photo img', count: 10
  end
end

您需要使用message expectations，例如：

it "asks the project to trigger all hooks" do
  expect(project).to receive(:execute_hooks).twice
  expect(project).to receive(:execute_services).twice
  expect(project).to receive(:update_merge_requests)

  PostReceive.new.perform(...)
end

关于邮寄者，请检查此其他answer

VCR将帮助您模拟http请求