サードパーティの Web サービスと統合するアプリに取り組んでいます。現在、Web サービスを呼び出して次のことを行う個別の統合/回帰テストがあります。
これらのテストのほとんどは、バグが発見されて修正されたときに作成されました。サード パーティの Web サービスは遅いので、テスト プロセスをスピードアップしようとしています。各テストは Web サービスを呼び出すため、Web サービスを 1 回だけ呼び出す 1 つのテストにそれらを結合すると、処理が大幅に高速化されます。
各テストは特定のバグに対して書かれているため、これらのテストを組み合わせることは悪い習慣でしょうか? 私の懸念は、リファクタリングのミスにより、後でバグが再導入される可能性があることです。
それらを個別に実行する機能を保持しない限り、それらを組み合わせることはお勧めしません (オーバーナイト ビルドではそれらを個別に保持し、継続的なビルドでは組み合わせてください)。
テスト フレームワークでサポートされている場合は、(個別の「ポリシー」で) それらを並列化してみてください。
はい、それらを組み合わせることは悪い習慣です。代わりに、テストを組み合わせずにリスクを軽減する方法を考えてください。1 つのアプローチ (おそらく最善の策) は、Web サービスをモック アウトすることです。これにより、回帰を検出する能力を危険にさらすことなく、テストがはるかに高速になります。もう 1 つの方法は、遅い回帰テストを、通常のテスト セットよりも実行頻度が低い (それでも十分な頻度で) 実行される独自のスイートに分割することです。最後に、それらを組み合わせることができますが、元のバグをすべてコードに明示的に再導入して、組み合わせたテストでもそれらが検出されることを確認することをお勧めします。
具体的で、指摘された、直接的な単体テストは非常に価値があります。何が壊れたのかを正確に知ることができてうれしいです。テストを組み合わせると、その価値が損なわれます。
夜間のビルドにそれらを含めることをお勧めします。そうすれば、あなたが眠っているときに時計を見ていないときに 1 日 1 回実行されるようになります。そして、開発者の時間テストでそれらを削除するだけです。
もちろん、それは一晩では十分ではないということを前提としています。
テストを 1 つの大きなテストにまとめただけでは、役に立たなくなったり、悪化したりする可能性があります。それは単にそれらを削除するよりもはるかに良いことではありません.