目次:
私たちは、サービス指向アーキテクチャの原則を優先します。 逆 。それは、明確に定義された責任を持つ、小さくて保守可能なコンポーネントがあることを意味します。それらはRepresentational State Transfer（REST）APIを介して（大部分）互いに通信します。
これは柔軟性を提供し、1つの重要な側面を除いて私たちによく役立ちました：テスト。テストするときは、避けるべきです：
- 同じマシン上で実行されている外部サービスへの依存。
- 遅いテスト
アプリケーションは本質的に外部サービスに依存しているため、それらの依存関係に対して適切なテスト戦略を用意することが重要です。
私たちは最近バイパスを使い始めました、そして私たちがそこにどのようにして到着したか、そして特にそれをどのように使っているかを説明します。
過去
メソッドをモックして、このようなサンプルデータを返します。
それがRuby / Railsの世界での「やり方」でした。残念ながら、これはJoséValimによって最もよく説明されているように悪い振る舞いを助長します。
それからExVCRを使い始めました。これは素晴らしいライブラリですが、モック/スタブと同じような欠点があります。それは怠惰さを助長し、明確に定義されたAPIにとって重要な懸念の分離を促進しません。 ＥｘＶＣＲは、実生活データを「記録」および「再生」することを可能にする。統合は非常に簡単です（テストに数行を含めるなど、その他のすべての処理は面倒を見ます）。しかし理想的には、テストでは外部の依存関係を抽象化するのではなく考える必要があります。エンドポイントの振る舞いを最小限のオーバーヘッドでテストする必要がある場合は、シナリオの実行可能な選択肢になるかもしれません（AmazonのS3のようなAWSサービスへの呼び出しをテストするために使用します）。
アダプターを入力してください
アダプタはうまく機能し、API契約および明確に定義された通信境界に関する議論を促進します。特にアダプタがより複雑な場合（JSON-RPCソケットのような場合）には、この方法を使用します。
これは、アダプタの外観です。
しかし、単純なHTTPエンドポイントの場合、アダプタは多くの作業のように見え、大きな欠点があります。それらは、消費するライブラリをテスト式から除外します。
現在と未来
バイパスを使用すると、使用する外部サービスをシミュレートするテストで非常に単純なWebサーバーを起動できます。
これで、HTTPライブラリ、JSONエンコード/デコードライブラリ、および認証メカニズムを含むスタック全体をテストできます。バイパスREADMEはよく書かれているので、実装の詳細については割愛します。しかし、テストを簡潔で読みやすくするために、使用方法を少し変更しています。
まず、テストが完全な統合スイートとして実行されているときに、Facebookに電話をかけたいことがあります。 Facebook APIが期待通りに機能するように、これを不定期に行います。追加中
- 統合を含める
に
混合テスト
APIをシミュレートするのではなく、代わりに外部サービスを呼び出します（5行目、7行目）。
Bypassを使用する各テストは、外部サービスへの要求をシミュレートするとき明示的です。
@tag facebook_bypass
（7行目）
最後に、
handle_fb
関数（30〜39行目）が呼び出されています（
request_path
に一致します。私たちはどのパスに反応しているのかを明確にし、異なるパスに対して異なる関数を定義することを可能にするので、関数ヘッドでのマッチングが好きです。
そのため、Bypassはでタグ付けされたテストでのみ実行されます。
@タグ：バイパス
そして私達が私達の統合スイートを実行していないとき。 Bypassの設定中にもう1つ行うことは、タグがページIDを渡すことを許可することです（8、20行目）。だからここにバイパスを使用してテストがどのようにそのすべての栄光に見えるかです：
ご覧のとおり、
facebook_bypass
tagは、APIをシミュレートしていることを明示的に示しています（統合モードになっていない限り）。これにより、シミュレートしたAPIに情報を渡すことができます。また、さまざまなテストに同じBypass設定を再利用することは非常に簡単です。
これが外部APIのテストに役立つことを願います。さらに質問がある場合は、Twitterで私を見つけることができます（下記参照）。