12

単体テストがほとんどない大規模なプロジェクトがあります。これからは、開発者が新しい機能 (またはバグ!) を、対応する単体テストの最小限のカバレッジなしでコミットするようにしたいと思います。

これを強制するにはどのような方法がありますか?

私たちは多くのツールを使用しているので、おそらくプラグイン (jira、greenhopper、fisheye、sonar、hudson) を使用できます。また、おそらく Subversion のプレコミット フック、jira のコミット アクセプタンス プラグイン、または同等のものを考えていました。

考え?

4

3 に答える 3

6

Build breakerプラグインを使用した Sonar (ちなみに素晴らしいツール) は、一部のメトリックが指定されたルールを満たさない場合に、Hudson ビルドを中断させる可能性があります。カバレッジが所定のポイントを下回ったときにアラートをトリガーする (最終的にビルドが失敗する) ようなルールを Sonar でセットアップできます。唯一の欠点は、おそらくカバレッジを拡大したいということです。そのため、アラート レベルを毎日現在の値まで上げることを忘れないでください。

于 2011-03-02T21:08:06.727 に答える
2

やりたいことは、何が新しいコードかを判断し、新しいコードが何らかのテストでカバーされていることを確認することです。

一般に、コード カバレッジの決定は、さまざまなテスト カバレッジ ツールのいずれかを使用して行うことができます。多くのテスト カバレッジ ツールは、アプリケーション全体を単純に再構築してから、テストを実行してカバレッジを判断できます。

私たちの (Semantic Designs の)テスト カバレッジツールのラインは、変更されたファイルのリストから、再計測が必要な個々のファイルだけを特定し、慎重にテストを編成することで、再実行が必要なテストだけを特定できます。これにより、テストを再実行するコストが最小限に抑えられ、全体的なカバレッジ データは同じになります。(実際、これらのツールは、メソッド レベルでの変更に基づいて、どのテストを行う必要があるかを検出します)。

テスト カバレッジ データを取得したら、知りたいのは、特定の新しいコードがいくつかのテストでカバーされていることです。変更されたファイルのカバレッジが 100% であると主張することで、変更されたファイルがわかっている場合は、カバレッジ データをテストするだけでこれをずさんに行うことができます。それはおそらく実際には機能しません。

代わりに、SD のSmart Differencer ツールを利用して、より正確な答えを得ることができます。これらのツールは 2 つの言語ファイルを比較し、言語構文 (ソース行の変更だけでなく、式、ステートメント、宣言、メソッド本体など) と概念編集操作 (移動、コピー、削除、挿入、名前の変更など) を使用して変更箇所を示します。ブロック内識別子)。SmartDifferencer のデルタは、単純な diff ツールから得られるものよりも小さくて細かい傾向があります。

SmartDifferencer の出力から、変更された行のリストを抽出するのは簡単です。ファイルごとに、テストカバレッジデータでカバーされている行との交点を計算できます。変更された行のすべてがカバーされた行のセット内に完全に含まれていない場合、「新しい」コードはテストされていないため、フラグを立てたり、チェックインを停止したり、チェックポリシーに違反していることを通知したりできます。

TestCoverage および SmartDifferencer ツールは、この計算が自動的に行われる状態ですぐに使用できるわけではありませんが、スクリプトを実装するのは非常に簡単です。

于 2011-03-02T22:18:17.840 に答える
0

Maven を使用する場合 - cobertura プラグインは良い選択です (開発者にとっては svn フックほど煩わしくありません) http://mojo.codehaus.org/cobertura-maven-plugin/usage.html

于 2011-03-02T21:20:16.120 に答える