少し前に、自分のコードとサードパーティ API の間で作成した統合をテストするテストを作成しました。このテストにより、統合が適切に機能し、期待される結果が得られることが確認されます。
サードパーティ API に接続しようとしたときにテストで 500 エラーが発生したため、正式なビルドは今日失敗しました。
このような状況をテストする意味はありますか?
3326 次
2 に答える
12
私の意見では、サードパーティ (db、webservice など) が利用できない場合、統合テストは失敗しても問題ありません。統合自体をテストしたくない場合は、単純な機能のみをテストして、API の結果をモックし、それらに対してテストできます。そのシナリオでは、テストはサードパーティの可用性に依存しなくなります。
私は通常、「統合」などのグループ属性を使用してサードパーティの可用性に応じて単体テストをマークし、継続的な統合プロセスから除外します。代わりに、夜間ビルドで実行させました。統合テストは一般に時間がかかります。継続的統合の要点は、迅速なフィードバックを提供することです。
于 2011-02-18T19:10:48.783 に答える
6
いいえ、サードパーティ サービスがダウンしているときにテスト スイートが失敗するのは役に立ちません。ただし、サービスとの統合を完全にテストする必要があります。次の戦略は私にとってうまくいきました：
サービスへの接続をカプセル化する以外に、サードパーティのサービスをモジュール (クラスとしましょう。ただし、言語のモジュール化は問題ありません) に分離します。クラスにメソッドを記述して、サービスの障害であるエラーと自分の障害であるエラーを区別できるようにします。たとえば、サービスダウンの例外に共通のスーパークラスを与えます。
サービス クラスの単体テストを記述して、
サービス ダウン エラーが発生した場合、テストは成功しますが、エラーがログに記録されます。
他のエラーが発生した場合は、通常どおり失敗します。
ライブ サービスに対して実行されるように、これらのテストを記述します。これらのテストは少数である必要があるため、テスト スイートの実行時に問題が発生することはありません。
統合テストを含む、他のすべてのテストからサービス クラスをスタブまたはモックします。(ここで言う「統合テスト」とは、サードパーティ サービスとやり取りするかどうかではなく、独自のコードのすべてのレイヤーをテストするテストのことです。)
統合テストからサービス クラスをスタブ化またはモック化する場合は、サービス クラスのパブリック API をスタブ化またはモック化するのではなく、より低いレベル (おそらくサービス クラスの内部メソッドまたは使用するライブラリ) をスタブ化またはモック化します。サービスに接続します。これにより、サービス クラスを呼び出すときの統合のバグが防止されます。単体テストでは、他のクラスと同様に、サービス クラスのパブリック API をスタブまたはモックします。
Martin Buberl が示唆しているように、サービス クラスがスタブ化またはモック化されていない統合テストを個別にテスト実行すると役立つ場合があります。正直なところ、これは私が関わってきた複数のプロジェクトで議論されてきたことですが、これまでに行われたことはないと思います. サードパーティのサービスに障害が発生した場合、テストで発見する前に、必ず製品エラー (監視またはカスタマー サポートによって報告されます) から発見します。
于 2016-02-01T14:06:56.797 に答える