web-dev-qa-db-ja.com

統合テストですが、どれくらいですか？

私のチーム内での最近の議論は私を不思議に思いました。基本的なトピックは、機能テストと統合テストでどの程度および何をカバーするかということです（確かに、それらは同じではありませんが、例は重要ではないのでダミーです）。

次のような「コントローラ」クラスがあるとします。

public class SomeController {
    @Autowired Validator val;
    @Autowired DataAccess da;
    @Autowired SomeTransformer tr;
    @Autowired Calculator calc;

    public boolean doCheck(Input input) {
        if (val.validate(input)) {
             return false;
        }

        List<Stuff> stuffs = da.loadStuffs(input);
        if (stuffs.isEmpty()) {
             return false;
        }

        BusinessStuff businessStuff = tr.transform(stuffs);
        if (null == businessStuff) {
            return false;
        }

       return calc.check(businessStuff);
    }
}

確かに多くの単体テストが必要です（たとえば、検証が失敗した場合、またはDBにデータがない場合など）、それは問題外です。

私たちの主な問題と私たちが同意できないことについては、どれだけの統合テストがそれをカバーするかということです:-)

統合テスト（テストピラミッド）を減らすことを目指します。これから私がカバーするのは、実行が最後の行から戻る単一の幸福不幸のパスだけです。これらをまとめて爆発しないかどうかを確認するだけです。

問題は、テスト結果がfalseになった理由を簡単に判別できないことであり、それによって一部の人はそれについて不安を感じます（たとえば、単に戻り値のみをチェックする場合、テストが緑色であることが隠されています）誰かが検証を変更してfalseを返したためです）。もちろん、すべてのケースをカバーできますが、それは非常にやりすぎです。

誰かがこの種の問題について良い経験則を持っていますか？または推奨ですか？読む？トーク？ブログ投稿？トピックについて何か？

よろしくお願いします！

PS：Sry醜い例については、特定のコード部分を例に変換するのは非常に困難です。ええ、例外をスローする/別の戻り値の型を使用するなどについて議論できますが、私たちの手外部依存関係のため、多かれ少なかれ拘束されています。

PS2：このトピックをSOここから移動しました（元の質問、マーク 保留中 ））

javaunit-testingtestingtest-automationintegration-testing
8
rlegendi

真剣に質問 統合テストの価値という考えの学校があります。

ここでは幅広い回答が得られると思いますが、私の考えでは、明確な価値を提供する場合にのみ使用すべきです。

まず、できる限り多くの単体テストを作成する必要があります。a）安価であり、b）ビルドサーバーで実行される唯一のテストである可能性があるためです（ある場合）。

クライアント側のテストを作成してデータベースや他の層を検証するのは魅力的ですが、可能であれば、統合テストを行うのではなく、適切なレベルでこれらのテストを行う必要があります。もちろん、これは、モックなどを機能させるために、インターフェースなどの形でいくつかの基礎を必要とする可能性があります。

テストの範囲も考慮してください。スイートの実行時やスモークテストの複製時に何が起こるかをカバーする統合テストを作成するだけの場合、これには制限があります。また、関連する場所へのログインを増やす方が、相互に接続された12のコンポーネントからあいまいなメッセージを受け取り、それを介して追跡する必要があるよりも、より良いオプションであるかどうかを検討してください。

したがって、何かを書くことにした場合、それらがいつ実行されるかを考える必要があります。彼らが起こっている厄介な問題を見つけることができればそれは素晴らしいことですが、開発者がそれらを実行することを決して覚えていなければ、それはかなり無意味になります。

最後に、統合テストは、煙のテストやユーザーのテストの完全に不適切な代替品です。まったく気にしない場合は、適切に設計されたテストプロセスの一部を形成する必要があります。

6
Robbie Dee

この答え とは対照的に、ソフトウェアテストプロセスの重要な部分で、さまざまなレベルでのテストを見つけます。ユニット、機能、統合、スモーク、受け入れ、その他の種類のテストは、さまざまなものをテストします。

そして、それらを自動化できれば、継続的インテグレーションのジョブとして実行できます（jenkinsなど）。誰もがテストが失敗したかどうかを確認できるため、破損したかどうかを確認するために実行する必要はありません。

私の統合テストでは、詳細には触れません。詳細とコーナーケースは単体テスト用です。私がテストするのは、すべての正しいパラメータを渡して、主な機能にすぎません。つまり、あなたの例では、統合テストでは、フォールスパスは取り上げません。

8
BЈовић