unit-testing - プロジェクトのコードカバレッジ率はどのくらいですか？

Question

プロジェクトの％コードカバレッジはどれくらいですか？理由が気になります。

開発チームはそれに満足していますか？そうでない場合、それを増やすことから何が妨げになりますか？

Stuart Hallowayは、プロジェクトが100％を目指しているものです（そうでなければビルドが壊れます！）。そのレベルの誰かがいますか？

私たちは苦痛な25％ですが、新しいコードでは80〜90％を目指しています。蒸発するときにそのままにしておくことにしたレガシーコードがあります（積極的に書き直しています）。

Answer 1

85％のコードカバレッジで実行していますが、それを下回ってもビルドは中断されません。重要な指標としてコードカバレッジを使用することは危険な行為だと思います。テストで何かがカバーされているからといって、カバー範囲が良いとは限りません。難しい事実としてではなく、私たちが弱くカバーされている領域のガイダンスとしてそれを使用しようとしています。

Answer 2

80％は、マイルストーンの終了基準です。スプリントを通過させない場合（事前に時間を計画している場合でも）、安定化によって追加します。特定のコンポーネントまたは機能について例外を認める場合がありますが、次のマイルストーンのためにPri1アイテムを開きます。

コーディング中、コードカバレッジはデイリービルドで自動的に測定され、レポートがチーム全体に送信されます。70％未満は黄色、50％未満は赤です。現在、ビルドは失敗しませんが、次のマイルストーンでこれを追加する予定です。

開発者がユニットテストと何の関係があるのか​​わからない。開発者は高品質の製品を構築するために雇われており、最低品質とそれを測定する方法を実施するプロセスが必要です。誰かがプロセスに満足していない場合は、他のコンポーネントと統合する前に、コードを検証する別の方法を自由に提案できます。

ところで、自動シナリオテストでもコードカバレッジを測定します。したがって、ユニット、シナリオ、および組み合わせの3つのアンバーがあります。

Answer 3

当社の目標は、例外処理コードを含め、80% のステートメント カバレッジです。個人的には、チェックインするすべての項目で 90% 以上を維持したいと思っています。

Answer 4

自動テスト スイートでコード カバレッジをよく使用しますが、主にテストされていない領域を探すためです。ほとんどの場合、カバー率は約 70% ですが、2 つの理由から 100% に達することはありません。

1) 通常、リリース後に新しい機能を自動化します。これは、最初のリリースで手動でテストされるため、カバレッジ分析には含まれません。この場合、自動化は主に機能回帰のためのものであり、コード カバレッジを実行して微調整するのに最適な場所です。

2) 100% のカバレッジを得るには、実行ハンドラーの内部に入る必要があるため、フォールト インジェクションが必要です。これを自動化するのは難しく、時間がかかります。現在これを行っていないため、100% になることはありません。James の Whittakers によるソフトウェアの破壊に関する書籍は、このテーマについて関心のある人なら誰でも十分にカバーしています。

SQAforumsのthisやthisなどのスレッドで定期的に議論されているように、コード カバレッジはテスト カバレッジと同じではないことも覚えておく価値があります。したがって、100% のコード カバレッジは誤解を招く指標になる可能性があります。

Answer 5

数年前、私は Perl のテスト カバレッジを測定しました。250 のテスト ケースの終わりまでに、コードの 70% と完全にテストされたブランチの 33% に達しました。

Answer 6

悲しいことに、私たちの職場ではまだ0％です。それを改善することを目指しますが、上司にそれが必要であることを伝えようとすると、彼らはテスト != コーディングの費用が少なくて済むため、簡単ではありません。

Answer 7

数年前に私が行ったプロジェクトでは、100% のライン カバレッジを達成しましたが、それを完全に制御できたので、目標を達成することができました。
現在、新しいコードの 50% をカバーするという目標があり、この数値は近い将来上昇しますが、それを測定する方法はありません。ユニット テストを毎晩実行するたびにコード カバレッジを測定するためのツールがすぐに用意されるので、私たちの立場は改善されると確信しています。