Faraday: 新しいドキュメントのテストページ

これを持ってきてくれてありがとう。 それに応えて、ファラデーテストアダプター＃1000を使用したライブテスト/ユニットとrspecの例を含むPRを投稿しました。 これは、外部テストダブルライブラリ（rspec、mocha、webmockなど）の代わりに、ファラデーをテストするための推奨される方法です。

タイムアウトや接続エラーなどをテストしていることに気づきませんでした。対象は眉をひそめているのか、PR＃998の使用方法だけなのか。

構文がわからないと思います

構文がわからないと思います

ああ、多分私はファラデーのテストドキュメントをもう一度見直す必要があります：/

＃1000の構文は、 Faraday::Adapter::Test::Stubsインスタンスを使用します。これは、ファラデーの要求/応答サイクルをテストするための排他的なスタブオブジェクトです。 これを使用して、特定のテストでhttpリクエストに対する模擬応答を設定できます。

  it 'parses name' do
    # this block yields a rack response: an array with:
    # response status, http header hash, and response body
    stubs.get('/ebi') do |env|
      [
        200,
        { 'Content-Type': 'application/javascript' },
        '{"name": "shrimp"}'
      ]
    end

    expect(client.sushi('ebi')).to eq('shrimp')
    stubs.verify_stubbed_calls
end

申し訳ありませんが、明らかにあなたの問題を十分に読んでいませんでした。 私はあなたが特に例外をテストしたかったことを完全に見逃しました。 このようなテストも機能します（これを＃1000に追加します）。

  it 'handles exception' do
    stubs.get('/ebi') do
      raise Faraday::ConnectionFailed, nil
    end

    expect { client.sushi('ebi') }.to raise_error(Faraday::ConnectionFailed)
    stubs.verify_stubbed_calls
  end

私は、このような特定のテストダブル実装を、より一般化されたモックアプローチよりも好みます。これは、ファラデーリクエストワークフロー全体を通過するためです。 開発者がとにかくRSpecモックを使用したい場合は、優れたRSpecドキュメントを使用する方が適切です。

＃1000で配信