コードカバレッジの品質に関する議論を否定するためのツール/提案
今では、この質問を重複して考えたり、何度も尋ねられたりする可能性があることを知っています。その場合、質問への回答とともに関連する質問へのリンクをいただければ幸いです。
私は最近、コードカバレッジについて何人かの人々と意見が一致していません。 100％のカバレッジは良質のテスト、つまり良質のコードを意味するものではないという議論に基づいて、コードカバレッジをまったく見ないでほしいと思っている人々のグループがあります。
私は、コードカバレッジが確かにテストされていないものを教えてくれて、それらの領域に集中するのを助けるという議論を売り払うことによって押し戻すことができました。
（上記は他のSOこのような質問で同様に議論されています https://stackoverflow.com/questions/695811/pitfalls-of-code-coverage ）
これらの人々からの議論は-次に、チームは低品質のテストを迅速に作成することで反応し、時間を無駄にしながら重要な品質を追加しません。
私は彼らの視点を理解していますが、より多くのカバレッジ基準に対応するより堅牢なツール/フレームワークを導入することで、コードカバレッジのより堅牢なケースを作成する方法を探しています(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc)。
私が探しているのは、そのようなコードカバレッジツールとそれに伴うプラクティス/プロセスの組み合わせについて提案です。私の推薦について快適です。
このような議論に対抗する方法についての経験/知識に基づく、付随するコメント/提案も歓迎します。主観的ですが、コードカバレッジは私のチームがコードの品質とテストの価値をより意識するのに役立ちました。
編集：典型的なコードカバレッジの弱点に関する私の理解についての混乱を減らすために、私は私が言及していないことを指摘したいと思いますStatement Coverage（または実行されるコード行）ツール（たくさんあります）。実際、ここに問題のあるすべての良い記事があります： http://www.bullseye.com/statementCoverage.html
私は、ステートメントまたはラインのカバレッジだけでなく、複数のカバレッジ基準とレベルについて詳しく調べていました。
参照： http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria
アイデアは、ツールが複数の基準に基づいてカバレッジを教えてくれれば、テスト品質の合理的な自動評価になるということです。ラインカバレッジは良い評価だと言っているわけではありません。実際、それが私の質問の前提です。
編集：
OK、多分私はそれを少し劇的に予測しましたが、あなたは要点を理解します。問題は、すべてのチームにわたってプロセス/ポリシーを一般的に、均一/一貫した方法で設定することです。また、テストの品質をどのように保証するか、何の対策も講じずに保証時間をどのように割り当てるかという懸念は一般的です。したがって、適切なプロセスと適切なツールでバックアップすると、無駄なプロセスに時間が費やされていないことを認識しながら、コードの品質を向上させることができるという測定可能な機能が好きです。
編集：これまでのところ、答えから私が持っているもの：
- コードレビューはテストの品質を保証するためにテストをカバーするべきです
- テストファースト戦略は、単にカバレッジ率を向上させるために、事実の後に書かれたテストを回避するのに役立ちます
- 単なるステートメント/行以外のテスト基準をカバーする代替ツールの探索
- カバーされたコード/見つかったバグの数の分析は、カバレッジの重要性を認識し、より良い事例を作るのに役立ちます
- 最も重要なことは、チームの入力を信頼して正しいことを行い、彼らの信念のために戦うことです
- 対象ブロック/テスト数-議論の余地ありますが、ある程度の価値があります
これまでに素晴らしい答えをありがとう。本当に感謝しています。このスレッドは、何時間にも及ぶ強力なブレインストーミングよりも優れています。
私の経験では、コードカバレッジは作成すると同じくらい便利です。すべてのケースをカバーするgoodテストを作成する場合、それらのテストに合格することは、要件を満たしていることを意味します。実際、それは テスト駆動開発 が使用するexactの考え方です。実装について何も知らずに、コードの前にテストを記述します（これは、別のチームがテストを完全に記述することを意味する場合があります）。これらのテストは、最終製品が仕様で行ったすべてのことを実行することを確認するために設定され、[〜＃〜]その後[〜＃〜]これらのテストに合格するための最小限のコードを記述します。
ここでの問題は、明らかに、テストが十分に強力でない場合、Edgeのケースや予期しない問題を見落として、仕様に完全に適合しないコードを作成することです。テストを使用してコードを検証することに真剣に取り組んでいる場合は、優れたテストを作成することが絶対に必要です。そうでなければ、本当に時間を無駄にしています。
質問の答えにはならないことに気づいたので、ここで回答を編集しました。私はそれを見て wiki記事 TDDのいくつかの明記された利点を確認します。それは本当に組織がどのように機能するかにかかっていますが、TDDは間違いなく業界で使用されています。
まず、人々doは100％のカバレッジを主張します：
ほとんどの開発者は、「100％ステートメントカバレッジ」を適切と見なしています。これは良いスタートですが、十分ではありません。 「100％ブランチカバレッジ」と呼ばれるものを満たすためのより良いカバレッジ標準ID、...
Steve McConnell、 Code Complete 、Chapter 22：Developer Testing。
あなたや他の人が述べたように、カバレッジのみのためのコードカバレッジは、それほど多くを達成する可能性は低いです。しかし、コード行を実行できない場合、なぜそれが書かれているのですか？
自分のプロジェクトに関するデータを収集して分析することで、この議論を解決することをお勧めします。
データを収集するために、私は個人的に次のツールを使用しています。
- JaCoCo および関連するEclipseプラグイン EclEmma コードカバレッジの測定用。
- Ant 自動ビルド、テスト、およびレポート用のスクリプト。
- Jenkins 継続的ビルドの場合-ソース管理の変更により自動ビルドがトリガーされます
- JaCoCoプラグイン for Jenkins-各ビルドのカバレッジメトリックをキャプチャし、傾向をグラフ化します。ビルドの正常性に影響を与えるプロジェクトごとのカバレッジしきい値の定義も許可します。
- Bugzilla バグの追跡用。
それ（または類似の何か）を配置したら、自分のデータをより詳しく調べ始めることができます。
- 十分にカバーされていないプロジェクトでより多くのバグが見つかりましたか？
- 十分にカバーされていないクラス/メソッドでより多くのバグが見つかりましたか？
- 等.
あなたのデータwillがコードカバレッジに関するあなたの立場をサポートすることを期待します。それは確かに私の経験でした。ただし、そうでない場合は、組織が希望よりも低いコードカバレッジ基準で成功する可能性があります。あるいは、あなたのテストはあまり良くないかもしれません。このタスクでは、コードカバレッジの不一致の解決策に関係なく、欠陥の少ないソフトウェアの作成に重点的に取り組むことが期待されます。
これらの人々からの議論は-チームはすぐに低品質のテストを作成することで反応するであり、重要な品質を追加することなく時間を浪費します。
これはtrustの問題であり、toolsではありません。
彼らがその発言を本当に信じるなら、彼らがチームにコードを書くことをまったく信頼するのはなぜでしょうか？
わかりました、多分私はそれを少し劇的に予測しましたが、あなたは要点を理解します。問題は、すべてのチームにわたって一般にプロセス/ポリシーを均一/一貫した方法で設定することです。
それが問題だと思います。開発者は、一貫したポリシーやグローバルポリシーを気にせず（多くの場合は優れた理由で）、企業のポリシーに準拠するのではなく、正しいと思うことを自由に実行したいと考えています。
グローバルなプロセスと手段が価値と開発の質とスピードにプラスの影響を与えることを証明しない限り、これは合理的です。
通常のタイムライン：
- dev：ねえ、見て-ダッシュボードにコードカバレッジメトリックを追加しました。
- マネージャー：確かに、それらに必須の目標とコンプライアンスを追加しましょう
- 開発者：気にしないで、コードカバレッジは愚かで役に立たないので、削除しましょう
私の経験では、メトリックを価値のあるものにするために、コードカバレッジと組み合わせることがいくつかあります。
コードレビュー
悪いテストを開発者にパントバックできる場合は、この意味のないカバレッジを提供している悪いテストの数を制限するのに役立ちます。
バグ追跡
モジュールに多数のコードカバレッジがあっても、その領域に多くの/重大なバグがある場合、その開発者がテストで改善を必要とする問題を示している可能性があります。
実用主義
重要なコードの適切なテストで100％に到達する人は誰もいません。チームリーダーとしてコードカバレッジを見て、「N％に到達する必要がある！」ギャップを特定し、システムにゲームをする機会を提供することなく、目標を達成する「モジュールXのカバレッジを改善する」ように人々に依頼します。
対象となるブロック/テスト数
ほとんどのコードカバレッジツールは、対象となるブロックと対象外のブロックを一覧表示します。これを実際のテストの数と組み合わせると、「広範囲」のテストの程度を示すメトリックを取得できます。これは、不良テストまたは結合デザインを示します。これは1つのスプリントから別のスプリントへのデルタとしてより便利ですが、考え方は同じです。コードカバレッジを他のメトリックと組み合わせて、より多くの洞察を得ます。
「チームは迅速に低品質のテストを作成することで反応するため、重要な品質を追加せずに時間を無駄にします」
これは単なる理論的なものではなく、実際のリスクです。
コードの超過だけでも機能不全の指標です。私はそのレッスンを難しい方法で学びました。かつて、バランスの取れた指標やプラクティスを利用できないことを強調しました。例外をキャッチしてマスクし、アサーションなしの何百ものテストは醜いものです。
「そのようなコードカバレッジツールとそれに伴うプラクティス/プロセスの組み合わせの提案」
他のすべての提案に加えて、テストの品質を評価できる1つの自動化手法があります。変異テスト（ http://en.wikipedia.org/wiki/Mutation_testing ）です。 Javaコードの場合、PIT（ http://pitest.org/ ）は機能します。これは、私が遭遇した最初の変異テストツールです。
ご指摘のとおり、コードカバレッジの欠如は、ソフトウェア品質リスクとして容易に特定できます。私は、コードカバレッジはソフトウェア品質の必要条件ですが不十分であることを教えます。ソフトウェアの品質を管理するには、バランスの取れたスコアカードアプローチを採用する必要があります。
これが私の2セントです。
ソフトウェア開発にメリットをもたらすことができるため、最近多くの注目を集めているプラクティスがあります。ただし、一部の開発者はこれらのプラクティスを盲目的に適用します。つまり、方法論の適用はアルゴリズムの実行と同様であり、正しい手順を実行した後、望ましい結果が得られると確信しています。
いくつかの例：
- 100％のコードカバレッジでユニットテストを作成すると、コード品質が向上します。
- TDDを体系的に適用すると、より良い設計が得られます。
- ペアプログラミングを行うと、コードの品質が向上し、開発時間が短縮されます。
上記のステートメントの基本的な問題は、人間はコンピュータではなく、ソフトウェアの作成はアルゴリズムを実行するようなものではないということです。
したがって、上記のステートメントにはいくつかの真実が含まれていますが、物事を少し単純化しています。
- 単体テストは多くのエラーをキャッチし、コードカバレッジはコードのどの部分がテストされるかを示しますが、ささいなことをテストすることは無意味です。たとえば、ボタンをクリックして対応するダイアログが開いた場合、ダイアログを開くコンポーネントにボタンイベントを送信するロジック全体を簡単な手動テスト（ボタンをクリックする）でテストできます。このロジックをテストしますか？
- TDDは優れた設計ツールですが、開発者が問題の領域を十分に理解していない場合はうまく機能しません（例 この有名な投稿 を参照）。
- 2人の開発者が一緒に作業できる場合、ペアプログラミングは効果的です。また、経験豊富な開発者は、最も重要な問題について簡単に説明してから個別にコーディングすることを好むかもしれません。彼らがすでに知っている多くの詳細について多くの時間を費やして、退屈で時間の無駄になる可能性があります。
コードカバレッジに戻ります。
私は、コードカバレッジが確かにテストされていないものを教えてくれて、それらの領域に集中するのを助けるという議論を売り払うことによって押し戻すことができました。
特定のモジュールを100％カバーする価値があるかどうかは、ケースバイケースで判断する必要があると思います。
モジュールは非常に重要で複雑な計算を実行しますか？次に、コードのすべての1行をテストするだけでなく、意味のある単体テスト（そのドメインで意味のある単体テスト）も記述します。
モジュールは、ボタンをクリックしたときにヘルプウィンドウを開くなどの重要でシンプルなタスクを実行しますか？手動テストの方が効果的でしょう。
これらの人々からの議論は-次に、チームは低品質のテストを迅速に作成することで反応し、時間を無駄にしながら重要な品質を追加しません。
私の意見では、それらは正しいです：100％のコードカバレッジを必要とするonlyによってコード品質を強制することはできません。カバレッジを計算して統計を作成するためのツールをさらに追加しても、役に立ちません。むしろ、コードのどの部分がより敏感で広範囲にテストする必要があり、どの部分がエラーが発生しにくいかについて話し合う必要があります（ユニットテストを使用せずにエラーをより簡単に発見および修正できるという意味で）。
100％のコードカバレッジを開発者にプッシュする場合、一部の人は、賢明なテストを作成する代わりに、彼らの義務を果たすために愚かなユニットテストを作成し始めます。
対策を講じずに保証時間をどのように割り当てますか
多分それはあなたが人間の知性と判断を測定できるという幻想です。有能な同僚がいて、彼らの判断を信頼している場合は、「このモジュールの場合、コードカバレッジを増やしてもメリットはほとんどないので、それに時間を費やさないでください」または「このモジュールには必要です。できる限りのカバレッジを実現するには、賢明な単体テストを実装するためにさらに1週間必要です。」.
したがって（ここでも、これらは私の2セントです）、すべてのチーム、すべてのプロジェクト、およびすべてのモジュールに適合する必要があるプロセスを見つけて、コードカバレッジなどのパラメーターを設定しないでください。そのような一般的なプロセスを見つけることは幻想であり、あなたがそれを見つけたとき、それは最適ではないだろうと私は信じています。
コードカバレッジは Hawthorne Effect の影響を受けやすいことを常に発見しました。このため、「ソフトウェアメトリックがなぜ存在するのですか？」そして答えは通常、次のようなプロジェクトの現在の状態をある程度理解することです。
「私たちはどれくらい近いですか？」
「このシステムの品質はどうですか？」
「これらのモジュールはどれほど複雑ですか？」
悲しいかな、プロジェクトの良し悪しを示す単一の指標は決して存在しないでしょう。単一の数値からその意味を導き出そうとすると、必然的に単純化しすぎてしまいます。指標はすべてデータに関するものですが、それらの意味を解釈することは、はるかに感情的/心理的なタスクであるため、異なる構成のチームや異なるドメインの問題に一般的に適用することはできません。
カバレッジの場合、コード品質のプロキシとして使用されることが多いと思います。そして、本当の問題は、非常に複雑なトピックを0から100までの単一の整数にまとめることです。もちろん、100％のカバレッジを達成するために無限の探求で役に立たない可能性のある作業を推進するために使用されます。ボブマーティンのような人々は、100％のカバレッジが唯一の深刻な目標であると言います。
もちろん、実際にコードベースを理解するのに役立たないカバレッジを取得する方法はたくさんあります。 toString（）をテストすることは価値がありますか？不変オブジェクトのゲッターとセッターはどうですか？チームは一定の時間内に応募するために多くの労力を費やしているだけで、その時間は常に完璧な仕事をするために必要な時間よりも短いようです。
良い近似を作成するのに役立つと判断したメトリックは Crap4J です。現在は機能していませんが、自分で簡単に移植/実装できます。 Crap4Jは、コードカバレッジを循環的複雑度に関連付けようとすることで、より複雑なコード（ifs、whiss、forsなど）のテストカバレッジが高くなることを示唆しています。私には、この単純なアイデアが本当に真実でした。コードベースのどこにリスクがあるかを理解したいのですが、本当に重要なリスクの1つは複雑さです。したがって、このツールを使用すると、コードベースの危険性をすばやく評価できます。それが複雑な場合は、カバレッジをさらに上げるほうがよいでしょう。そうでなければ、コードのすべての行をカバーするために時間を無駄にする必要はありません。
もちろん、これは1つのメトリックとYMMVにすぎません。それがあなたにとって意味があるかどうか、そしてそれがあなたのチームにプロジェクトがどこにあるのかについてかなりグロッキーな感じを与えるかどうかを理解するためにそれに時間を費やす必要があります。
コードカバレッジは確かに、それらが正しいという点で、優れた単体テストの証拠にはなりません。
しかし、すべての単体テストが優れていることを証明する方法を提供できない限り（優れたものの定義に関係なく）、これは実際にはミュートポイントです。
過去にさかのぼって既存のコードをカバーするのが最善の方法だとは思いません。私は、あなたが書いた新しいコードや変更したコードのカバーテストを書くことは理にかなっていると私は主張します。
バグが見つかったら、そのバグが原因で失敗するテストを記述し、テストが緑色になるようにバグを修正します。テストのコメントに、それが書かれているバグを入力してください。
目標は、予期しない副作用を心配せずに変更を加えることができるように、テストを十分に信頼することです。テストされていないコードを飼いならすためのアプローチの良い要約については、レガシーコードの効果的な使用をご覧ください。