VCRGemを使用してテストスイートを改善する方法

Rubyアプリケーションが何らかの外部APIを使用している場合は、おそらくテストとAPIレートの制限が遅いという問題に直面している可能性があります。 。

解決策は何ですか？

クライアントライブラリからHTTPメソッドを手動でスタブし、事前に決定された応答を返すことができます。

しかし、それは多くの作業と醜いコードです！

より良い解決策は、 Webmock+VCRのような宝石の強力な組み合わせを使用することです。 。

WebMockは、次のような一般的なHTTPライブラリからのHTTPリクエストをインターセプトします。

• net / http
• ファラデー
• RestClient
• …もっとたくさん！

これだけでも便利ですが、それでも応答データを提供する必要があります。

ここでVCRが登場します…

VCRはWebMockと組み合わせて機能し、コードによって作成されたHTTP応答を記録します 。

これらの録音は「カセット」と呼ばれます。

テストを実行するとき ：

VCRはカセットファイルをロードし、記録された応答を返します。実際のAPIを尋ねる必要がないため、応答が速くなります。

いくつかのコード例を見てみましょう！

VCRコード例

この例では、次のセクションで説明するように、VCRとの統合が優れているため、RSpecを使用します。

テストするコードは次のとおりです ：

require "faraday"
require "json"

class Github
  def self.user(name)
    url  = "https://api.github.com/users/#{name}"
    data = Faraday.get(url).body

    JSON.parse(data, symbolize_names: true)
  end
end

Github APIにリクエストを送信して、特定のユーザーに関する情報を取得します。非常にシンプルですが、VCRの仕組みを学ぶのに役立ちます。

このコードのテストは次のようになります ：

require "rspec/autorun"

require_relative "github_api_example"

describe Github do
  let(:user_response) { Github.user("ruby") }

  it "can fetch & parse user data" do
    expect(user_response).to be_kind_of(Hash)

    expect(user_response).to have_key(:id)
    expect(user_response).to have_key(:type)
  end
end

これは実際のAPIにヒットして合格しますが、完了するまでに約0.5秒かかります。

1回のテストで0.5秒！

それほど多くはないように思われるかもしれませんが、100個のテストがあると想像してください。つまり、すべてを実行するのに50秒かかります。

それを修正する時が来ました…

このコードを追加してVCRを紹介しましょう ：

require "vcr"

VCR.configure do |c|
  c.cassette_library_dir = "spec/vcr"
  c.hook_into :webmock
end

このコードはtest_helperに追加できます ファイルなので、すべてのテストで利用できます

このconfigureで カセットファイルを保存する場所をVCRに指示し、WebMock統合を有効にすることをブロックします。

FaradayまたはExconを使用している場合、VCRはそれらに直接接続できます。

:webmockを置き換えるだけです :faradayを使用 、または:excon 。

次へ ：

カセットの名前と、これらの下で実行するコードをVCRに伝える必要があります。

方法は次のとおりです ：

let(:user_response) do
  VCR.use_cassette("github/user") { Github.user("ruby") }
end

テストを実行すると、VCRはcassette_library_dirの下にファイルを作成します 、この場合、ファイル名はspec/vcr/github/user.yamlになります 、フォローしている場合は、それを確認することをお勧めします。

今すぐテストを実行すると、はるかに高速になります 。

実際…

完了するのにかかる時間はわずか0.01秒です！

「VCRが処理方法を知らないというHTTPリクエストが作成されました」

このエラーメッセージが表示された場合は、次の2つのいずれかを意味します。

1. VCRを有効にしてHTTP呼び出しを行おうとしていますが、VCR.use_cassetteの外部にあります ブロック。

解決策 ：デフォルトでは、VCR+WebMockはすべてのHTTPリクエストをブロックします。これは、構成オプションを使用して変更したり、欠落しているVCRブロックを追加したり、RSpecメタデータを使用したりできます（次のセクション）。

2.別のリクエストを作成し、このURLと一致しないカセットを使用しようとしています。たとえば、テストで/users/rubyをリクエストした場合 、テストを/users/appleに変更すると、カセットはこのURL専用に作成されます カセットが別のURL用であるため、このエラーが表示されます。

解決策 ：URLごとに異なるカセットを使用し、new_episodesを有効にします 記録モード（vcr: { record: :new_episodes } ）または、リクエストURLを更新した後、古いカセットを削除します。

RSpecメタデータの使用方法

VCR.use_cassette メソッドは、この宝石を使用するための良い方法です。

しかし…

VCRにカセットを自動的に作成させることもできます。

どのように？

これをVCR.configure内に追加します ブロック：

c.configure_rspec_metadata!

これで、特定のテストに対してVCRを有効にできます（it ブロック）、またはテストグループの場合（describe 。

このように ：

describe Github, :vcr do
  # ...
end

これにより、テストの説明にちなんで名付けられたカセットファイルが作成されます ：

spec/vcr/
└── Github
    ├── can_parse_user_data.yml
    └── can_test_vcr.yml

これにより、テストごとに1つのカセットが作成されることに注意してください…

2つのテストが同じリクエストを行い、同じデータを使用する場合でも。 VCRはそれらのために別々のカセットを作成します。

役立つVCRオプションとヒント

カセットに問題がある場合、またはデータの新しいバージョンが必要な場合は、カセットファイルを削除できます 。

VCRは新しいAPI応答を記録し、問題を解決する可能性があります。

しかし、そうでない場合はどうなりますか？

デバッグモードを有効にできます VCR.configureで ：

VCR.configure do |c|
  # ...
  c.debug_logger = $stderr
end

これにより大量の出力が生成される可能性があるため、テストを関心のあるものだけに制限してください。

次へ ：

API応答の一部としてAPIキーまたはその他の機密データがあるとしましょう…

記録からそのデータをフィルタリングすることをお勧めします。

方法は次のとおりです ：

VCR.configure do |c|
  # ...
  c.define_cassette_placeholder("<API_KEY>", ENV["API_KEY"])
end

概要

WebMockとVCRのgemを使用して、外部APIの応答を待たずにRubyアプリのテストを作成できるようにする方法を学びました。

これが気に入ったら、この記事を共有することを忘れないでください。そうすれば、より多くの人が楽しむことができます。

読んでくれてありがとう🙂