unit-testing - 単体テストはコードカバレッジとどのように関連していますか？

Question

コードカバレッジがメトリックであることは知っていますが、単体テストについての記事でよく言及されています。しかし、単体テストを設計するとき、私は自分のビジネスロジックのテストを作成しようとしており、カバレッジについてはあまり気にしません。では、その関係は何ですか？

Answer 1

考え方は次のようになります。

単体テストを実行するときに実行されるコードが、テストするクラス (テスト対象のシステム、SUT) のすべてのコードをカバーしている場合、関連するすべてのコードを明らかにテストしたことになります。
したがって、SUT のコード カバレッジが高いことは良いことです。

しかし、誤解を招く可能性もあります。コード カバレッジが 100% であっても、すべてのビジネス ロジックを実際にテストしたわけではありません。そのため、すべてのビジネス ロジックのテストに集中することは、実際にはより優れたアプローチです。
すべてのビジネス ロジックをテストした場合、コード カバレッジは 100% になります。または、ビジネス ロジック内の必要のないコードもあります。
それでも、コード カバレッジを使用して、すべてのビジネス ロジックを実際にテストしたかどうかを確認できます。

要約すると、次のようになります。

1. SUT の 100% のコード カバレッジがない場合は、完全なビジネス ロジックをテストしていないことを強く示唆しています。
2. BUT: 100% のコード カバレッジは、すべてのロジックをテストしたことを保証するものではありません

Answer 2

コード カバレッジをオンにした単体テストは、非常に強力なツールとなります。

例えば。メソッドをテストすると、すべてのロジック パスに到達したかどうかを確認できます。そうでない場合は、さらにテストが必要です。コードのセクションをヒットできない場合は、副作用なしで削除できることを知っています。

Answer 3

文字通り「単体テスト」は、単一のユニット、つまり単一のコンポーネントをテストします。したがって、単体テストは必ずしもビジネス要件をカバーするわけではなく、コンポーネントのすべての部分が意図したとおりに機能することを確認します。コード カバレッジは、テストされて検証されたコードの割合を測定します。テストされていないすべてのコードにはおそらく欠陥が含まれている可能性があるため、高いコード カバレッジ結果が望まれます。

もちろん、単体テスト、または単体テストの実装に使用されるフレームワークを使用して、一度に複数のコンポーネントをテストすることもできます。これらのテストは、非常に低いレベルではありますが、統合テストに似ています。

コード カバレッジと統合 (またはビジネス ロジック テスト) の関係は、100% のコード カバレッジがあれば、すべてのコンポーネントが本来の機能を果たしていることがわかるということです。しかし、アプリケーションが本来の機能を確実に実行するようにしたい場合は、高いコード カバレッジでは不十分です。この追加の統合テスト (一度に複数のコンポーネントをテストするテスト) には、十分ではありません。