コードが自動的にカバーされていることをどのように確認しますか？

CI / CDワークフローでTDDにプッシュするために、いくつかの新しいプロジェクト用にBambooサーバーをセットアップしているところです。確かに、単体テストは素晴らしいですが、そこにあるのと同じくらいログだけです。

これは、特定のブランチ（つまり、開発ブランチとメインリリースブランチ）のGIT事前受信フックでより良いかもしれませんが、コードカバレッジを実施する場合は、どのように実施する必要がありますか。私はコミッターを信頼してコードがカバーされていることを確認できて嬉しいですが、勤勉さと一貫性を除いて、これらの事柄をどのように維持するのでしょうか？

要するに、コミット段階またはビルド段階のいずれかで、他の人がどのようにテストカバレッジを自動プロセスとして実施するかを確認したいと思います。

コードカバレッジを自動的に適用しないでください。

これは、メソッドごとにコードの最大行数を強制するのと似ています。同意します。ほとんどのメソッドは、たとえば20 LOC未満である必要がありますが、メソッドがそれよりも長い場合もあります。

同様に、クラスごとに特定の割合のコードカバレッジをターゲットにすると、望ましくない結果が生じる可能性があります。例えば：

• ボイラープレートコードクラスまたはコードジェネレーターによって作成されたクラスは、まったくテストされない場合があります。開発者にそれらをテストするように強いることは何の利点もありません、そしてそれをするのに費やされた時間の面でかなりのコストがかかります。

• アプリケーションの重要でない部分を処理する単純なコードは、必ずしもテストする必要はありません。

• 一部の言語では、一部のコードをテストできません。私は、C＃でこのメソッドを使用し、ライブラリの匿名メソッドを使用して、コードカバレッジを100％にしたいと思っていました。これらのケースは、開発者にとって意気消沈する可能性があります。

さらに重要なことに、コードカバレッジはコードの2つの側面に比例する必要があります。

• アプリケーションの主要な機能の一部である複雑なロジックを含むコードは、失敗や回帰が重要な結果をもたらす可能性があるため、慎重にテストすることをお勧めします。

• 誰も使用しない機能を処理する単純なコードには、基本的なケースのみをカバーする基本的なテストがある場合があります。

もちろん、測定値としてコードカバレッジを使用することもできます。特に、異なるチームがコードカバレッジを達成する方法を比較するために使用します。テストに関して、規律が厳しくなく、より消極的なチームが存在する場合があります。このような場合は、この指標を、バグの数、バグの解決に費やした時間、コードレビュー中のコメントの数などの他の指標と組み合わせることができます。

あなたはまた、少なくとも強制することがあり、いくつかの個々のプロジェクトで、¹、コードカバレッジを60％と言うことは理にかなって、それが可能に除外として、開発者が特定のクラスをマークするために作る（プロトタイプを除外するように注意してください、などのコード、CRUDを、生成されました）コードカバレッジからも素晴らしい²です。この場合、コードカバレッジが必要な最小値を下回っている場合、ビルドに失敗するチェックの形式でこれを行うことができます。私が考え、構築段階でそれを行う段階をコミットしていないことから、あなたがコミット時にユニットテストを実行することが期待されていません。

^{code私はコードベースに基づいて60％を妥当な最小値と見なします。コードカバレッジが60％未満のほぼすべてのプロジェクトまたはクラスは、実際にはテストされていません。これは、言語や会社によって大きく異なる場合があります（会社によっては、0％が標準です）。何が正常で何が高すぎるかをチームと話し合うようにしてください。多分彼らは絶えず95％に達していて99％を簡単にターゲットにすることができます、あるいは多分彼らはコードカバレッジを70％から75％に増やすのに苦労しています。}

^{²最終的な悪用はコードレビュー中に検出されるため、開発者にこの可能性を与えることを恐れないでください。これは、リンターまたはスタイルチェッカーによるチェックからコードの一部を除外する可能性に似ています。JSLint、StyleCop、およびコード分析は、除外がサポートされている3つの例であり、乱用を助長することなく実際に役立ちます。}

次のコードを検討してください。

rsq = a*a + b*b;
if (rsq >= 0.0) {
    r = sqrt(rsq);
}
else {
    handle_this_impossible_event();
}

そのelseブランチに到達するテストケースを作成する方法はありません。しかし、これが安全上重要な飛行ソフトウェアである場合、負の値を送信することに対する保護sqrtが存在しない場合、人々は著者の訴訟をすべて覆います。通常、rsq = a*a + b*b平方根の計算と抽出は、複数行のコードで区切られます。その間、宇宙線は符号ビットをオンにすることができrsqます。

実際、フライトソフトウェアはに相当するものをhandle_this_impossible_event()複数回呼び出しています。通常、これには制御の冗長コンピューターへの切り替え、疑わしいコンピューターの正常なシャットダウン、疑わしいコンピューターの再起動、そして最後に疑わしいコンピューターがバックアップの役割を果たします。これは、主な飛行コンピュータがワッコを使用するよりもはるかに優れています。

飛行中のソフトウェアであっても、100％のコードカバレッジを達成することは不可能です。これを達成したと主張する人々は、些細なコードを持っているか、これらの不可能なイベントに対する十分なテストを持っていません。

テストカバレッジは、プロジェクトの全体的な状態の有用な指標です。高いテストカバレッジにより、ソフトウェアが展開時に期待どおりに機能するかどうかについて、十分な情報に基づいた決定を行うことができます。テストカバレッジが低い場合は、単に推測しているだけです。カバレッジを自動的に測定するツールが存在します。これらは通常、デバッグコンテキストでプログラムを実行するか、実行されたコードに簿記操作を挿入することによって機能します。

テストにはさまざまな種類があり、カバレッジメトリックにはさまざまな種類があります。一般的なカバレッジメトリックには、関数カバレッジ、ステートメントカバレッジ、分岐カバレッジ、条件カバレッジがありますが、その他にもあります。

• ユニットテストは、1つの概念的なユニット（モジュール、クラス、メソッドなど）の実装がその仕様に準拠しているかどうかをチェックします（TDDでは、テストは仕様です）。独自の単体テストのないユニットは危険フラグですが、統合スタイルのテストでカバーされる可能性があります。

  単体テストはほぼ完全な関数カバレッジを意味する必要があります。単体テストはそのユニットのパブリックインターフェイス全体を実行するため、これらのテストに影響されない機能はありません。既存のコードベースに単体テストを導入する場合、関数カバレッジは大まかな進捗インジケーターです。

  単体テストでは、ステートメントのカバレッジ（75％〜100％）を適切にカバーする必要があります。ステートメントカバレッジは、単体テストの品質指標です。総カバレッジが常に可能であるとは限らないため、95％を超えてカバレッジを改善するよりも、時間をより有効に活用することができます。

  分岐と条件のカバレッジはよりトリッキーです。コードの一部がより複雑または重要であるほど、これらのメトリックは高くなります。しかし、目立たないコードの場合は、ステートメントのカバレッジが十分である傾向があります（すでにブランチカバレッジが少なくとも50％であることを意味します）。1つのユニットの状態カバレッジレポートを確認すると、より適切なテストケースを構築するのに役立ちます。

• 統合テストでは、複数のユニットが互いに正しく動作するかどうかを確認します。統合テストは、カバレッジメトリックを高く評価しなくても非常に役立ちます。統合テストは通常​​、ユニットのインターフェースの大部分を実行します（つまり、高い機能カバレッジを持ちます）が、これらのユニットの内部はすでにユニットテストでカバーされています。

コードがメインブランチにマージされる前にテストを実行することは良い考えです。ただし、プログラム全体のテストカバレッジメトリックの計算には時間がかかる傾向があります。これは、夜間のビルドに最適なジョブです。これを行う方法を理解できる場合、Gitフック内の変更されたユニットでのみ変更されたテストまたはユニットテストを実行するのが適切な妥協案です。テストの失敗は、「作業中」のコミット以外では受け入れられません。選択したカバレッジメトリックがしきい値を下回った場合（たとえば、ステートメントカバレッジが80％を下回った場合、または対応するテストがない新しいメソッドが導入された場合）、これらの問題は警告として扱い、開発者がこれらの潜在的な問題を修正する機会を得ます。ただし、これらの警告を無視する十分な理由がある場合もあり、開発者もそうできるはずです。

テストは適切ですが、テストが多すぎると煩わしくなります。迅速で適切なフィードバックは、品質への注意を促すのに役立ちますが、価値を生み出すのに邪魔をしたくありません。個人的には、手動でテストを実行することを好みます。これにより、作業している部分に関するフィードバックをより迅速に得ることができます。リリース前に、静的分析、プロファイラー、コードカバレッジツールを使用して問題のあるゾーンを見つけるという品質重視の取り組みを行います（これらの手順の一部はリリース前のテストスイートの一部です）。

誰も突然変異テストに言及していません。それらの背後にあるアイデアは非常に実用的で直感的です。

それらは、ソースコードをランダムに変更して（例： ">"を "<"に切り替えて）、つまり突然変異を起こして、これらの無計画な変更がテストに失敗するかどうかをチェックします。

そうでない場合、a）問題のコードは不要であるか、またはb）（可能性が高い）このコードの一部はテストによってカバーされていません。

もちろん、コードカバレッジデータは自動的に取得できますが、他の人がすでに説明している理由により、それらに基づいて自動決定を行うことはできません。（あいまいすぎて、エラーの余地が多すぎます。）

ただし、次善の策は、コードカバレッジに関するプロジェクトの現在の状態が人間によって定期的にチェックされる確立されたプロセスを持つことです。おそらく、プロジェクトマネージャーの受信トレイに毎日のレポートが届きます。

エンタープライズ環境では、Hudson、Jenkinsなどの継続的インテグレーションツールを使用してこれを実現します。これらのツールは、ソースコードリポジトリからプロジェクト全体を定期的にチェックアウトし、ビルドして、テストを実行し、レポートを生成するように構成されています。もちろん、コードカバレッジモードでテストを実行し、これらのレポートに結果を含めるように構成できます。

JetbrainsによってTeamCityも作成されます。これは、私には少し軽量で、小規模なソフトウェアショップに適しているようです。

そのため、プロジェクトマネージャーは定期的にコードカバレッジレポートを受け取り、自分の適切な判断を使用し、必要に応じて執行者として行動します。

一般的な意見にもかかわらず、RationalのPurifyツールスイートにはコードカバレッジ機能が含まれていますが、コードカバレッジは自動的にチェックできます。すべての関数の計測（バイナリの処理、各関数の更新、または追加のコードの呼び出し）に依存していたため、ユーザーに表示されるデータを書き出すことができました。特に当時はかなりクールなテクノロジー。

しかし、100％のカバレッジを得るために本当に一生懸命試みたとしても、70％程度しか管理できませんでした。だから、それは少し無意味な練習です。

ただし、単体テストを作成する状況では、100％の単体テストカバレッジはさらに無意味だと思います。すべてのゲッターやセッターではなく、ユニットテストを必要とするメソッドをユニットテストしてください！ユニットテストは、トリッキーな関数（またはクラスTBH）を検証することであり、緑色のチェックマークが表示されるプロセスまたはツールでボックスにチェックを入れないようにする必要があります。

このためのツールを作成しました

https://github.com/exussum12/coverageChecker

使用する

bin/diffFilter --phpunit diff.txt clover.xml 70

ユニットテストの対象となる差分の70％未満の場合、失敗します。

差分を取得します。

git diff origin/master... > diff.txt

あなたがマスターから分岐し、マスターに戻ってマージすると仮定します

コードのphpunitフラグを無視してください。これは実際には単なるクローバーチェックなので、クローバーを出力できるものなら何でも使用できます。

他の回答がこれを100％にすることを提案したので、良い考えではありません