私は最近TDDを使い始めました。または、プロジェクトのテストを言うことができます。そこで、テストプロセス中にコードがどれだけカバーされているかを示す「コードカバレッジ」と呼ばれる新しいもの（私にとっては新しいもの）を見つけました。そして、ほとんどの高齢者が、100% のコード カバレッジを実現することは不可能である、または 100% のコード カバレッジを実現するのは適切ではない、とよく言っていることを私は知っています。このことは、このコードカバレッジがどのように機能するか、つまり、どのベースのコードをカバーしているのか疑問に思っています。Testingの主な使い方を教えてください。
この質問にコードカバレッジの画像を添付しています。
実際には、100% のコード カバレッジが可能ですが、言語によって少し異なります。
100% コード カバレッジの有用性について:
コード カバレッジが 100% であっても、コードが完全であることを意味するわけではありません。
添加：
100% のコード カバレッジが必要ない場合 (すべてに時間がかかるため、費用がかかるため)、まずコード内のリスクの高い領域に注目します。最初は些細な方法を飛ばして、複雑でリスクの高い機能から始めます。
また、単体テストを「支援」するために、設計パターンまたはコード構造を使用することも重要です。
まず、コード カバレッジの価値を理解するには、コード カバレッジで何を達成したいのかを理解する必要があります。コード カバレッジは、プログラム コードの品質を判断するのに役立ちます。たとえば、堅牢かエラーが発生しやすいか、まとまりがあるか、隠れた依存関係があるか、変更が容易かどうかなどです。
コード カバレッジの高いコードは、より優れたコードになる傾向がありますが、それが優れたコードであるという保証はありません。これは、コードの品質が、テスト ケースがどれだけうまく構築されているかに大きく依存するためです。たとえば、意図した動作を適切にテストしているか、誤った入力や破壊的な入力をテストしているか、コーナー ケースやその他の特殊なケースをテストしているかなどです。記述した場合でも、高い (または 100%) コード カバレッジを達成できますが、コードの品質は低くなります。
第 2 に、ほとんどの経験豊富な開発者が 100% のテスト カバレッジは必要ない、または悪い習慣でさえあると言う理由は、コード カバレッジを 100% にするために投資する必要がある時間は、より完全なテスト スイートに投資する方がよいからです。通常、100% のコード カバレッジを達成するのは、適切に設計されたテスト スイートよりも、作成が不十分なテスト スイートの方が簡単です。
第 3 に、完全なテスト スイートを (ほとんど) 手に入れることはできないため、コードがうまくいかない可能性のあるすべてのケースを検討できる人を多く知らないため、テスト スイートを継続的に修正する緊急性を開発する必要があります (完全なコード カバレッジの誤った伐採に落ち着くのではなく、無限に)。
コード カバレッジに関するこの見解が、皆さんにとってより役立つものになることを願っています。
コード カバレッジは重要です。高いほど、単体テストが完全であり、コードのその領域をカバーしていることを示し、バグが少なくなります。
MSTest は分岐、状態のカバレッジを提供せず、void メソッドのテストが困難な場合があるため、アプリケーションのコード カバレッジが 100% に達しない可能性があります。表示される統計は、ステートメント/関数のカバレッジに基づいています。