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

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

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

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：醜い例を試してみてください。ただし、特定のコード部分を例に変換するのは非常に困難です。ええ、例外を投げる/別の戻り値の型を使用するなどについて議論することができます。しかし、私たちの手は、外部の依存関係のため、多かれ少なかれ拘束されています。

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

統合テストの価値に真剣に疑問を投げかける学派があります。

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

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

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

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

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

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

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

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

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