私の会社には、単体テストまたは統合テストのいずれかで、75% のテスト カバレッジに到達するという規則があります。システム全体が複雑であるため、開発者は、依存するサービス/クラスを嘲笑する負担を取り除く代わりに、統合テスト (実行中のアプリケーションに対して Selenium Webdriver を使用するなど) を作成する傾向があります。
私はその友人ではなく、i-tests のテスト カバレッジ データが実際に何を意味するのか疑問に思っています。
私の意見では、テストは期待される動作を定義し、それをテストする必要があります。i-test が多くのサービスを介してアプリケーションの奥深くに入り、DB レイヤーに到達して再び戻る場合、多くの行がカバーされますが、そのようなカバーされた行の予想される動作がまったく明らかではありません。 . したがって、カバレッジ データの品質は疑わしいものであり、さらに悪いことに、メンテナンス作業が増加します。
そのPOVは正しいですか？経営陣との話し合いになると、どのようにバックアップできますか?
テスト カバレッジに関するブラインド パーセンテージ ルールは、実際には理想的ではありません。統合テストはその完璧な例です。何かが壊れた場合、何が壊れたのか正確にわかりますか? 複数の統合ポイントがある場合 (たとえば、単一の要求がデータベース、Web サービスにヒットし、電子メールを送信する場合) はどうでしょうか? テストが本当に意味を持つには、あまりにも多くのことが行われています。
考えられるすべての結果をテストせずに、100% のカバレッジを確保できますか? 10,000 個のテストを作成しても、ソフトウェアの最も重要なクラスをカバーできないでしょうか? 盲目的なメトリクスは良くなく、品質に実際の結果をもたらすことはありません。
通常、より小さく、より離散的なテストを行う方がはるかに価値があります。これは、統合ポイントをスタブ化し、テストでモック化することによって行います。次に、「データベースがこれを行う場合、私のコードはこれを行う」というシナリオを設定できます。この種の問題は、正確に同じことを繰り返すようにデータベースを設定するよりも、メモリ内で解決する方がはるかに簡単です。サーバー切断の統合テストをどのように自動化しますか? それはとても難しいです。特定の SQL 例外を処理するデータベースをスタブ化することは、はるかに簡単で繰り返し可能です。
期限までにテスト カバレッジの 75% に到達できなかった場合、または到達できたとしても残りの 25% はどうなるでしょうか。テストカバレッジのパーセンテージ。セレンまたはいわゆるものを使用しているにもかかわらず、信頼できる方法でアプローチの方法を説明してください。