先日、コードカバレッジツールと対応するレポートの使用について、さまざまな開発者とプロジェクトリーダーの間で激しい議論がありました。
- プロジェクトでコードカバレッジを使用していますか？使用している場合は、使用しないのはなぜですか？
- コードカバレッジはビルドまたは継続的インテグレーションの固定部分ですか、それとも時々使用しますか？
- レポートから得られた数値をどのように処理しますか？
11 に答える
4
コードカバレッジを使用して、テスト作業で大きな部分が欠落していないことを確認します。マイルストーンかそこらで、完全なカバレッジレポートを実行し、数日かけて結果を分析し、見逃した領域のテストカバレッジを追加します。
それを正当化するのに十分な定期的に分析するかどうかわからないため、ビルドごとに実行するわけではありません。
ヒットしていないコードの大きなブロックのレポートを分析します。これが最も効率的な使用法であることがわかりました。以前は、特定のコードカバレッジ目標を達成しようとしましたが、ある時点を過ぎると、収益は非常に減少します。代わりに、コードカバレッジをツールとして使用して、何も忘れていないことを確認することをお勧めします。
于 2009-02-13T06:30:35.380 に答える
3
1）はい、コードカバレッジを使用します
2）はい、それはCIビルドの一部です（なぜそうではないのですか？）
3）重要な部分-私たちは100％のカバレッジを求めていません。私たちが探しているのは、バグのある/複雑なコードです。これは、単体テストから簡単に見つけることができ、Devs/Leadsはシステムのデリケートな部分を認識します。このようなコード領域のカバレッジが良好であり、時間の経過とともに増加することを確認します。必要なテストなしで人々がより多くの修正をハックするにつれて減少することはありません。
于 2009-02-13T06:33:18.493 に答える
2
コードカバレッジを確認する方法は、カバーされていない量を確認し、カバーされていない理由を見つけることです。コードカバレッジは、単体テストの実行中にコード行がヒットしていることを示しているだけです。コードが正しく機能するかどうかはわかりません。100％のコードカバレッジは適切な数値ですが、中規模/大規模のプロジェクトでは、達成するのは非常に困難です。
于 2009-02-18T23:07:33.107 に答える
2
コード カバレッジは、「バグ キャッチ」ネットがどれほど大きいかを示しますが、ネットに穴がどれだけ大きいかはわかりません。
絶対的な指標としてではなく、テストの取り組みを評価するための指標として使用してください。
100% のカバレッジを提供し、何もテストしないコードを作成することは可能です。
于 2009-02-13T07:28:11.013 に答える
1
重要なプロジェクトのコード カバレッジを測定するのが好きです。すでに述べたように、恣意的/魔法のパーセンテージを達成することにあまり夢中にならないようにしてください. 複雑さに基づくリスク、パッケージ/名前空間によるカバレッジなど、より優れた指標があります。
同様のアイデアについて は、こちらの Cloverダッシュボードのサンプルをご覧ください。
于 2009-02-13T06:48:49.190 に答える
1
ビルドでこれを行い、85% などの値を下回らないようにします。また、カバーされていない最大のトップ 10 メソッドを自動的に実行して、何からカバーするかを判断します。
于 2009-02-13T07:00:55.603 に答える
0
1）はい、単純なノードカバレッジを測定します。理由は次のとおりです。
- 現在のプロジェクトで簡単に実行できます*（Rails Webアプリ）
- それは私たちの開発者がテストを書くことを奨励します（テストがアドホックだったバックグラウンドから来るものもあります）
2）コードカバレッジは、継続的インテグレーションプロセスの一部です。
3）レポートの数値は、次の目的で使用されます。
- 最小レベルのカバレッジを適用します（それ以外の場合は95％、ビルドは失敗します）
- テストする必要のあるコードのセクションを見つける
システムには、テストがそれほど役に立たない部分があります（通常、外部システムを処理するためにモックオブジェクトを利用する必要がある場合）。ただし、一般的にカバレッジが良好であれば、プロジェクトの保守が容易になります。修正や新機能が既存の機能を壊さないことは知っています。
*レールに必要なカバレッジを設定するための詳細：最小制限95先
于 2010-03-14T16:35:27.157 に答える
0
私たちはコード カバレッジを使用しており、ナイトリー ビルドに統合されています。カバレッジ データを分析するためのツールがいくつかあり、一般的にレポートされます。
- ステートメントカバレッジ
- 支店カバレッジ
- MC/DC カバレッジ
+ 90% のステートメントとブランチのカバー率に達すると予想しています。一方、MC/DC のカバレッジは、テスト チームにとってより広い意味を持ちます。ちなみに、カバーされていないコードについては、正当化の記録が必要です。
于 2009-02-13T07:22:59.827 に答える
0
コード自体に依存していることがわかります。SO ポッドキャスト #38 での Joel の発言は繰り返さないが、結論は「実用的になろう」ということだ。
コード カバレッジは、アプリのコア要素で優れています。
私はコードを依存関係のツリーと見なします。葉が機能する場合 (基本的な UI やユニット テスト済みの DAL を呼び出すコードなど)、それらを開発または更新したときにそれらをテストした場合、それらが機能する可能性が高くなります。動作し、バグがあったとしても、見つけたり修正したりするのは難しくないので、いくつかのテストのモックアップにかかる時間はおそらく時間の無駄になります。はい、依存しているコードの更新が影響する可能性があるという問題がありますが、これもケースバイケースであり、依存しているコードの単体テストでカバーする必要があります。
コードのトランクまたはブランチに関して言えば、機能のコード カバレッジ(各機能ではなく) は非常に重要です。
たとえば、私は最近、炭素排出量を計算するために一連の計算を必要とするアプリを作成するチームに所属していました。私はすべての計算をテストする一連のテストを作成しました。そうすることで、依存性注入パターンが正常に機能していることを確認できてうれしかったです。
必然的に、政府の法律の変更により、方程式にパラメーターを追加する必要があり、100 以上のテストはすべて失敗しました。
タイプミスのテスト（一度テストできた）に加えて、それらを更新することに気付きました。数学のユニット/回帰テストを行い、代わりにアプリの別の領域を構築することに時間を費やしました。
于 2009-02-13T11:51:05.343 に答える
0
Agile/XP に切り替える多くのチームは、コード カバレッジを、テスト自動化作業の ROI を測定する間接的な方法として使用しています。
私はそれを実験と考えています - 「単体テストを書き始めれば、コードカバレッジが向上する」という仮説があります - CI を介して対応する観測を自動的に収集し、グラフなどで報告することは理にかなっています。
この結果を使用して大まかな点を検出します。たとえば、より多くのカバレッジへの傾向がある時点で横ばいになった場合、何が起こっているのかを尋ねるのをやめます。おそらく、チームは関連するテストを書くのに苦労しています。
于 2009-02-13T07:05:09.807 に答える
0
コードカバレッジを使用して、テストに大きな穴がないことを確認し、CI で夜間に実行しています。
また、スタック全体で実行される selenium-web テストの完全なセットがあるため、追加のカバレッジ トリックも行います。
カバレッジを実行して Web アプリケーションをセットアップします。次に、セレン テストの完全に自動化されたテスト バッテリーを実行します。これらのいくつかはスモークテストのみです。
テストの完全なスイートが実行されると、カバレッジを調べてコードを検査するだけで、疑わしいデッド コードを特定できます。これは、大規模なプロジェクトで作業する場合に非常に便利です。しばらくすると、デッド コードの大きなブランチができるからです。
どのくらいの頻度でこれを行うかについて、固定された指標は実際にはありませんが、キーを 1 回か 2 回押すだけで実行できるようにすべて設定されています。
于 2009-02-13T07:09:45.070 に答える