私はブラウンフィールド アプリケーション開発の大ファンです。間違いなく素晴らしい本であり、世界中のすべての開発者にお勧めします。私がここにいるのは、コード カバレッジに関する本の要点に到達したからです。私の新しいショップでは、自動ビルド/継続的インテグレーションに Team City を使用しており、ビルドが完了するまでに約 40 分かかります。ブラウンフィールドの本は、摩擦のない開発と、開発者が耐えなければならない一般的な負担をどのように軽減したいかについて語っています。私が読んだのは130ページです。
「コード カバレッジ: 1 つの価格で 2 つのプロセス? リスト 5.2 のサンプル ターゲットからわかるように、最終的に 2 つの出力ファイルになります。1 つはテスト結果で、もう 1 つはコード カバレッジ結果です。これは、実際にこのタスク中にテストを実行しています。
コード カバレッジ タスクを実行している場合、技術的には別のタスクでテストを実行する必要はありません。このため、多くのチームはテスト タスクの代わりに自動化されたコード カバレッジ タスクを使用し、基本的に CI プロセスで両方のアクションを実行します。CI サーバーはコードをコンパイルしてテストし、チェックインごとにコード カバレッジ統計を生成します。
このアプローチに概念的な問題はありませんが、いくつかの欠点に注意してください。まず、コード カバレッジ統計の生成にはオーバーヘッドがあります。多くのテストがある場合、このオーバーヘッドは、長時間実行される自動ビルド スクリプトの形で摩擦を引き起こすのに十分なほど大きくなる可能性があります。メイン ビルド スクリプトは、チーム メンバーが頻繁に実行できるように、できるだけ速く実行する必要があることに注意してください。実行に時間がかかりすぎる場合、開発者が回避策を探していることがあります。
これらの理由から、ビルド スクリプトのデフォルト タスクとは別にコード カバレッジ タスクを実行することをお勧めします。これは定期的に実行する必要があります。おそらくビルド ファイル内で、隔週または月 1 回実行される別のスケジュールされたタスクとして実行する必要がありますが、チェックごとに実行することによる余分なオーバーヘッドを保証するほど、メトリクスには十分なメリットがあるとは思えません。の。"
これは、ビルドごとに NCover を実行する現在のショップでの慣行に反しています。私は主任に行き、これをしないように要求したいのですが、私にできる最善のことは、「これはブラウンフィールドの本が言っていることです」と彼に伝えることです. それだけでは十分ではないと思います。ですから、このトピックに関するあなたの個人的な経験とアドバイスを私に記入してくれることに頼っています. ありがとう。