コードカバレッジ品質の議論に反論する方法に関するツール/提案

今、私は人々がこの質問を複製したり何度も質問したりすることを考えることができることを知っています。その場合、関連する質問へのリンクと私の質問への回答に感謝します。

私は最近、コードカバレッジについて何人かの人々と意見が分かれています。私は、100％のカバレッジは高品質のテスト、したがって高品質のコードを意味しないという議論に基づいて、チームにコードカバレッジを完全に削除することを希望する人々のグループがいます。

私は、コードカバレッジがテストされていないことを確かに伝えており、それらの領域に集中するのに役立つという議論を売り払うことによって押し戻すことができました。

（上記は、このような他のSO質問で同様の方法で議論されています-/programming/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

アイデアは、ツールが複数の基準に基づいてカバレッジを教えてくれれば、それがテスト品質の合理的な自動評価になるということです。私は決して回線カバレッジが良い評価だと言っているわけではありません。実際、それが私の質問の前提です。

編集：
わかりました、多分私はそれを少し劇的に投影しすぎたかもしれませんが、あなたはポイントを得ます。問題は、すべてのチームに共通のプロセス/ポリシーを同種/一貫した方法で設定することです。また、テストの品質をどのように保証するのか、何の対策も講じずに保証時間をどのように割り当てるのかという懸念が一般的です。したがって、適切なプロセスと適切なツールでバックアップすると、無駄なプロセスに時間を費やしていないことを認識しながら、コードの品質を改善できる測定可能な機能が好きです。

編集：これまでのところ私が答えから持っているもの：

• コードレビューは、テストの品質を確保するためにテストをカバーする必要があります
• Test First戦略は、事実の後に書かれたテストを回避して、カバレッジを単純に増加させるのに役立ちます％
• 単純なステートメント/行以外のテスト基準をカバーする代替ツールの探索
• カバーされたコード/見つかったバグの数の分析は、カバレッジの重要性を評価し、より良いケースを作るのに役立ちます
• 最も重要なことは、正しいことを行い、彼らの信念のために戦うというチームのインプットを信頼することです。
• 対象ブロック/テスト数-議論の余地あり

これまで素晴らしい答えをありがとう。本当に感謝しています。このスレッドは、その能力を持つブレインストーミングの時間よりも優れています。

私の経験では、コードカバレッジはあなたが作成したのと同じくらい便利です。すべてのケースをカバーする適切なテストを作成する場合、それらのテストに合格すると、要件を満たしたことになります。実際、それはテスト駆動開発が使用する正確なアイデアです。実装について何も知らずに、コードの前にテストを記述します（別のチームが完全にテストを記述することを意味する場合があります）。これらのテストは、最終製品は、あなたの仕様は、それが行われると言うことすべてを行いいることを確認するように設定されており、THEN、あなたはそれらのテストに合格するために必要最小限のコードを記述します。

ここでの問題は、明らかに、テストの強度が十分でない場合、エッジケースや予期しない問題を見逃して、本当に仕様に合わないコードを書くことです。テストを使用してコードを検証することに真剣に取り組んでいる場合、適切なテストを書くことは絶対に必要です。そうでなければ、本当に時間を浪費しています。

あなたの質問に本当に答えていないことに気付いたので、ここで答えを編集したかったのです。私はそのwikiの記事を見て、TDDの利点を説明します。それは本当にあなたの組織が最高に機能する方法に帰着しますが、TDDは間違いなく業界で使用されているものです。

まず、人々は 100％のカバレッジを主張しています：

ほとんどの開発者は、「100％ステートメントカバレッジ」を適切と見なしています。これは良いスタートですが、ほとんど十分ではありません。「100％ブランチカバレッジ」と呼ばれるものを満たすためのより良いカバレッジ標準ID ...

Steve McConnell、コード完了、第22章：開発者テスト。

あなたや他の人が述べたように、カバレッジだけを目的としたコードカバレッジでは、ほとんど達成できません。しかし、コード行を実行できない場合、なぜそれが書かれているのですか？

自分のプロジェクトに関するデータを収集して分析することにより、議論を解決することをお勧めします。

データを収集するには、個人的に次のツールを使用します。

• コードカバレッジを測定するためのJaCoCoおよび関連するEclipseプラグインEclEmma。
• 自動化されたビルド、テスト、およびレポート用のAntスクリプト。
• 継続的なビルドのためのジェンキンス -ソース管理の変更は自動ビルドをトリガーします
• Jenkins用JaCoCoプラグイン -各ビルドのカバレッジメトリックをキャプチャし、傾向をグラフ化します。また、ビルドの状態に影響するプロジェクトごとのカバレッジしきい値の定義を許可します。
• バグを追跡するためのBugzilla。

それ（または同様のもの）を準備したら、自分のデータをより詳しく調べ始めることができます。

• カバーが不十分なプロジェクトでさらにバグが見つかりましたか？
• 不十分にカバーされたクラス/メソッドでより多くのバグが見つかりましたか？
• 等

データがコードカバレッジに関するあなたの立場をサポートすることを期待しています。それは確かに私の経験でした。しかし、そうでない場合は、組織が望むよりも低いコードカバレッジ標準で成功する可能性があります。または、テストがあまり良くないかもしれません。このタスクは、コードカバレッジの不一致の解決に関係なく、欠陥の少ないソフトウェアの作成に焦点を当てることを期待しています。

これらの人々からの議論は次のとおりです。チームは低品質のテストを迅速に作成することで対応し、重要な品質を追加することなく時間を無駄にします。

これは信頼の問題であり、ツールではありません。

彼らが本当にその声明を信じるなら、彼らはチームにコードを書くことを信頼するだろう、と彼らに尋ねてください。

はい、多分私はそれを少し劇的に投影しすぎたかもしれませんが、あなたはポイントを得る。問題は、すべてのチームに共通のプロセス/ポリシーを同種/一貫した方法で設定することです。

それが問題だと思います。開発者は、一貫したポリシーまたはグローバルなポリシーを気にせず（多くの場合、優れた理由により）、企業ポリシーに準拠するのではなく、自分が正しいと思うことを自由に実行したいと考えています。

グローバルなプロセスと手段が価値を持ち、開発の品質と速度にプラスの効果があることを証明しない限り、これは妥当です。

通常のタイムライン：

1. dev：ちょっと、見て-ダッシュボードにコードカバレッジメトリックを追加しました。
2. マネージャー：確かに、それらに必須の目標とコンプライアンスを追加しましょう
3. 開発者：気にしないでください、コードカバレッジは愚かで役に立たないので、ドロップしましょう

私の経験では、メトリックを価値のあるものにするために、コードカバレッジと組み合わせることがいくつかあります。

コードレビュー

悪いテストを開発者にパントできれば、この意味のないカバレッジを提供している悪いテストの数を制限するのに役立ちます。

バグ追跡

モジュールに多数のコードカバレッジがあるが、それでもその領域で多く/重大なバグが発生する場合、その開発者がテストで改善が必要な問題を示している可能性があります。

プラグマティズム

自明ではないコードの良いテストで100％に到達する人はいません。チームリーダーとしてコードカバレッジを見て、「N％に到達する必要がある！」と言うのではなく、ギャップを特定し、人々にシステムをゲームする機会を提供せずに目標を達成する「モジュールXのカバレッジを改善する」ように依頼します。

対象ブロック/テスト数

ほとんどのコードカバレッジツールは、対象ブロックと対象外ブロックをリストします。これを実際のテストの数と組み合わせることで、「広範な」テストがどのようなものであるかを示すメトリックを取得できます。これは、不良テストまたは結合設計を示します。これは、あるスプリントから別のスプリントへのデルタとしてより便利ですが、考え方は同じです。コードカバレッジを他のメトリックと組み合わせて、より多くの洞察を得ます。

これが私の2セントです。

ソフトウェア開発にメリットをもたらすことができるため、最近多くの注目を集めている多くのプラクティスがあります。ただし、一部の開発者はそれらのプラクティスを盲目的に適用します。彼らは、方法論の適用はアルゴリズムの実行に似ており、正しい手順を実行した後、必要な結果が得られると確信しています。

いくつかの例：

• 100％のコードカバレッジで単体テストを作成すると、コードの品質が向上します。
• TDDを体系的に適用すると、より良い設計が得られます。
• ペアプログラミングを行うと、コードの品質が向上し、開発時間が短縮されます。

上記のステートメントの基本的な問題は、人間はコンピューターではなく、ソフトウェアを書くことはアルゴリズムを実行するようなものではないということです。

したがって、上記のステートメントにはいくつかの真実が含まれていますが、物事をあまりにも単純化しすぎています、例えば：

• 単体テストは多くのエラーをキャッチし、コードカバレッジはコードのどの部分がテストされるかを示しますが、些細なことをテストするだけでは役に立ちません。たとえば、ボタンをクリックして対応するダイアログが開く場合、ボタンイベントをダイアログを開くコンポーネントに送信するロジック全体を簡単な手動テスト（ボタンをクリック）でテストできます。このロジックをテストしますか？
• TDDは優れた設計ツールですが、開発者が問題の領域を十分に理解していないとうまく機能しません（たとえば、この有名な投稿を参照）。
• ペアプログラミングは、2人の開発者が一緒に作業できる場合に効果的です。そうでなければ、災害になります。また、経験豊富な開発者は、最も重要な問題について簡単に話し合ってから、別々にコーディングすることを好む場合があります。

コードカバレッジに戻ります。

私は、コードカバレッジがテストされていないことを確かに伝えており、それらの領域に集中するのに役立つという議論を売り払うことによって押し戻すことができました。

特定のモジュールを100％カバーする価値があるかどうか、ケースごとに判断する必要があると思います。

モジュールは非常に重要で複雑な計算を実行しますか？次に、コードのすべての行をテストするだけでなく、意味のある単体テスト（そのドメインで意味のある単体テスト）を書きたいと思います。

モジュールは、ボタンをクリックしたときにヘルプウィンドウを開くなど、重要だが簡単なタスクを実行しますか？手動テストの方がおそらく効果的です。

これらの人々からの議論は次のとおりです。そして、チームは低品質のテストをすばやく作成することで反応し、重要な品質を追加することなく時間を無駄にします。

私の意見では、彼らは正しい：あなたは100％のコードカバレッジを必要とするだけでコード品質を強制することはできません。カバレッジを計算し、統計を作成するためのツールを追加しても、役に立ちません。むしろ、コードのどの部分がより機密性が高く、広範囲にテストする必要があり、どの部分がエラーを起こしにくいかについて議論する必要があります（ユニットテストを使用せずにエラーをより簡単に発見および修正できるという意味で）。

開発者に100％のコードカバレッジをプッシュすると、賢明なテストを作成しようとする代わりに、一部の人は義務を果たすために愚かなユニットテストを作成し始めます。

対策を講じずに保証時間をどのように割り当てますか

たぶん、それはあなたが人間の知性と判断を測定できるという幻想です。有能な同僚がいて、彼らの判断を信頼しているなら、彼らが「このモジュールについては、コードカバレッジを上げてもほとんどメリットがありません。だから、このモジュールに時間をかけないでください」または「このモジュールのためにできるだけ多くのカバレッジを得るには、賢明な単体テストを実装するためにさらに1週間必要です。」

そのため（ここでも2セントです）、プロセスを見つけようとせず、すべてのチーム、すべてのプロジェクト、すべてのモジュールに適合するコードカバレッジなどのパラメーターを設定しないでください。そのような一般的なプロセスを見つけることは幻想であり、あなたがそれを見つけたとき、それは次善であると信じています。

「チームは、低品質のテストを迅速に作成することで対応し、時間を無駄にしながら、重要な品質を追加しませんでした」

これは、理論上のリスクだけでなく、本当のリスクです。

コードの超過分だけでも機能不全のメトリックです。私はそのレッスンを難しい方法で学びました。かつて、私はバランスの取れたメトリックやプラクティスが利用できないことを強調しました。例外をキャッチしてマスクし、アサーションなしの何百ものテストは見苦しいものです。

「こうしたコードカバレッジツールとプラクティス/プロセスを組み合わせて使用​​することを提案する」

他のすべての提案に加えて、テストの品質を評価できる自動化手法が1つあります。それは、突然変異テスト（http://en.wikipedia.org/wiki/Mutation_testing）です。Javaコードの場合、PIT（http://pitest.org/）が機能します。これは、私が出会った最初の突然変異テストツールです。

ご指摘のとおり、コードカバレッジの欠如はソフトウェア品質リスクとして容易に識別できます。コードカバレッジはソフトウェアの品質にとって必要ですが、不十分な条件であることを教えます。ソフトウェアの品質を管理するには、バランスの取れたスコアカードアプローチを採用する必要があります。

コードカバレッジは、正しいという点で、優れた単体テストの証拠ではありません。

しかし、すべての単体テストが優れていることを証明する方法を提供できない限り（優れた定義が何であれ）、これは本当にミュートポイントです。

コードカバレッジは、ホーソン効果の影響を受けやすいことが常にわかっています。これにより、「なぜソフトウェアメトリックスがあるのですか？」答えは通常、プロジェクトの現在の状態について、次のような高いレベルの理解を提供することです。

「私たちはどれくらい近いですか？」

「このシステムの品質はどうですか？」

「これらのモジュールはどのくらい複雑ですか？」

残念ながら、プロジェクトがどれだけ良いか悪いかを示すことができる単一のメトリックはありません。また、単一の数値からその意味を導き出そうとすると、必然的に過度に単純化されます。メトリックスはすべてデータに関するものですが、それらの意味を解釈することははるかに感情的/心理学的なタスクであり、したがって、おそらく異なる構成のチームまたは異なるドメインの問題に一般的に適用することはできません。

カバレッジの場合、それはコード品質のプロキシとして使用されることが多いと思いますが、粗雑なものではありません。そして本当の問題は、非常に複雑なトピックを0から100までの単一の整数に要約することであり、これはもちろん、100％のカバレッジを達成するための無限のクエストで潜在的に役に立たない作業を駆動するために使用されます。Bob Martinのような人々は、100％のカバレッジが唯一の重大な目標であると言うでしょう。

もちろん、カバレッジを取得する方法はたくさんありますが、実際にはコードベースを理解するのに役立ちません。たとえば、toString（）をテストすることは価値がありますか？不変オブジェクトのゲッターとセッターはどうですか？チームは決まった時間に応募するだけの努力をしており、その時間は常に完璧な仕事をするのに必要な時間よりも短いようです。

適切な近似を作成するのに役立つとわかったメトリックはCrap4Jです。現在は機能していませんが、自分で簡単に移植/実装できます。Crap4J は、より複雑なコード（if、while、forsなど）がより高いテストカバレッジを持つ必要があることを暗示することにより、コードカバレッジを循環的複雑度に関連付けようとします。私にとって、この単純なアイデアは本当に真実でした。コードベースのどこにリスクがあるのか​​を理解したいのですが、本当に重要なリスクの1つは複雑さです。したがって、このツールを使用すると、コードベースがどれほど危険であるかをすばやく評価できます。複雑な場合は、カバレッジを大きくしてください。そうでない場合は、コードのすべての行をカバーしようとして時間を無駄にする必要はありません。

もちろん、これは1つのメトリックとYMMVにすぎません。それがあなたにとって意味があるかどうか、そしてそれがあなたのチームにプロジェクトがどこにあるのか合理的に不愉快な感覚を与えるかどうかを理解するためにそれと時間を費やす必要があります。

戻って既存のコードをカバーするのが最善の方法であるとは言いません。私は、あなたが書く新しいコードやあなたが変更するコードのためのカバーテストを書くことは理にかなっていると主張します。

バグが見つかったら、そのバグが原因で失敗するテストを記述し、テストが緑色になるようにバグを修正します。テストのコメントに、どのバグが書かれているかを記入してください。

目標は、予期しない副作用を気にせずに変更できるように、テストに十分な自信を持たせることです。テストされていないコードを手直しするためのアプローチの概要については、「レガシーコードを効果的に使用する」を参照してください。