18

問題

それは私が考えたい非常に一般的な問題です。新しいコードを追加するとリグレッションにつながり、既存のテスト ケースは時代遅れになります。コード内の依存関係は、この特定の回帰を修正する方法を知っていたとしても、求心性と遠心性の両方の方向でさらに n 個の場所で間接的な回帰が発生する可能性があることを意味します。

要件

SVN、Maven + Nexus、Sonar、Jenkins、および JIRA、QC、QTP を実行しているショップがあります。全体として、優れた CI 環境です。

すべての新しいビルドで、回帰の新しいケースがあります。Java パッケージの依存関係を双方向で見つけ、テスト ケースを適切に更新して、すべてのタイプの回帰 (直接および間接) をカバーしたいと考えています。私の単体テストのカバレッジは 50% に近づいておらず、統合テストの自動化が開発に追いついていないため、これはより大きな問題です。

私のオプション

  1. ソナー
  2. Google CodePRO
  3. Jアーキテクト
  4. Jtest (ベンダーの Parasoft と話し合いました。このためのツールはありません)
  5. アトラシアンのプラグインなど、既存の環境を活用する
  6. Kalisitck (ベンダーのデモ - 優れたツール - 学習曲線とコストがかかる)
  7. Coverity (Kalistick のようなもの - 学習曲線と複雑なインストール。非常に高価なライセンス。
  8. 他のオープンソース/有料のものはありますか?

JArchitect、SONAR、および CodePro は、thisまたはthisのような単純な Matrix を提供します。これは、影響を受けるユーザーと使用者のクラスを教えてくれるので、私の要件の半分を満たしています。私が望むのは、さらに一歩進んで、どの対応するテスト ケースが影響を受けるか、回帰リスクをカバーするためにそれらを更新および/または実行する必要があるかどうかをツールに教えてもらうことです。

Kalistick、Coverity、そしておそらく他の人が私が望むことをするかもしれません-それらはセットアップと構成が重く、システムに合わせてゆっくりと成長するため、すぐには生産的ではなく、コストがかかり、学習曲線が必要です.

短い質問

インストール、学習曲線、コスト、可用性、またはその他のパラメーターなどのすべての要因を考慮して、上記のどのツールをセットアップで使用するか。

に関する FAQ セクションを読んでいます。、 https://stackoverflow.com/questions/3716203/automatic-code-quality-and-architecture-quality-static-code-analysisおよび コード メトリクスの魅力は何ですか? および多くのリンクされたものですが、私の特定の質問には答えません。

4

7 に答える 7

2

役立つかもしれないいくつかのツール。それらのすべてがCIと統合されているわけではないことに注意してください。

iPlasmaは素晴らしいツールです

CodeProは、コードと設計の問題（重複したコード、カプセル化を破るクラス、間違ったクラスに配置されたメソッドなど）の検出に役立つEclipseプラグインです。（現在Googleに買収されています）

Reliefは、Javaプロジェクトの次のパラメーターを視覚化するツールです。パッケージのサイズ、つまり、視覚化されるアイテムの種類が含まれるクラスとインターフェイスの数（パッケージとクラスはボックスとして表され、インターフェイスとタイプのフィールドは球として表されます）。アイテムが使用されている重さ（重力、つまり中心の距離として表される）依存関係の数（深さとして表される）。

Stan4jは、数百ドルの商用ツールです。これはJavaプロジェクトのみを対象としており、Sonarに非常に近い（または、より良いレポートかどうかはわかりません）。Eclipseとの統合が良好です。

Intellij依存関係分析

あなたの問題から私が理解できたのは、2つのOOメトリックを追跡する必要があるということです -Efferent Coupling（Ca）とAfferent Couplings（Ce）。これにより、必要なパッケージに絞り込むことができます。ビルドごとに、Ca、Ceメトリックに基づいて必要なクラスを強調表示できるEclipseプラグインを作成する機会を探ることができます。

于 2013-01-07T12:11:46.257 に答える
2

接触するコードを追跡することで、どのテストが関連しているかを把握できます。テストカバレッジツールを使用して、彼らがどのコードに触れたかを追跡できます。

ほとんどのテストカバレッジツールは、実行中のテストが実行する場所の明示的なセットを構築します。それが「カバレッジ」のポイントです。一度に1つの単体テストを実行するように実行中のテストを編成し、カバレッジデータのスナップショットを作成すると、テストごとに、どのコードがカバーされているかがわかります。

コードが変更されると、変更されたコードの共通部分と個々のテストがカバーする内容を判別できます。交差点が空でない場合は、必ずそのテストを再実行する必要があり、おそらく更新する必要があります。

この作業を行うには、いくつかの実際的な問題があります。

まず、テストカバレッジツールがこの測位データをどのように記録するかを理解するのは難しいことがよくあります。次に、テストごとにキャプチャするためのテストメカニズムを取得する必要があります。それは整理するのが難しいかもしれません、そして/またはカバレッジデータは抽出して保存するのが不器用かもしれません。第三に、テストによって「変更されたコード」と「カバーされたコード」の共通部分を計算する必要があります。これは、抽象的には、大きなビットベクトルを交差させる際の問題です。最後に、「コード変更」のキャプチャは、コードが移動することがあるため、少し注意が必要です。ファイル内の位置100がテストされ、行がファイル内を移動する場合、比較可能な位置データを取得できない可能性があります。それは誤検知と誤検知につながります。

カバレッジデータを簡単にキャプチャできる形式で記録し、計算を実行できるテストカバレッジツールがあります。コードの変更を判断するのは難しいです。diffを使用できますが、移動したコードによって問題が多少混乱します。そのような動きを識別するコード構造を比較するdiffツールを見つけることができるので、より良い答えを得ることができます。

ソースコードスライサーがある場合は、テストされた出力が入力に（後方スライスで）どのように依存するかを計算できます。そのスライス内のすべてのコードは、明らかにテストに影響を与えます。ここでの悪いニュースは、そのようなスライサーを入手するのは簡単ではないということだと思います。

于 2013-01-09T03:40:29.800 に答える
2

JDependを使用すると、パッケージ間の依存関係を分析し、単体テストを作成して依存関係を確認したり、Fitnessと統合して優れた依存関係テーブルテストを実行したりすることもできます。テストが特定のパッケージに含まれている場合、これは役立つ場合があります...

于 2013-01-03T09:48:16.710 に答える
2

問題に対して見つけることができる最良のツールは、実際にはツールではなく、実践です。テスト駆動開発（Lasse Koskelaの本を参照）とExample by Example（Gojko Adzicの本を参照）について読むことを強くお勧めします。

これらのプラクティスを使用すると、2つのことが根本的に変わります。

  1. 100％に近いテストカバレッジがあります
  2. テストは一級市民になり、コードの中心になります

これがあなたの質問に関連していると思う理由は、あなたのシナリオがテストの正反対の役割を示唆しているからです。人々はコードの変更を実行し、「ああ、いや...今私は理解しなければならない」と思うでしょう。私がそれらのいまいましいテストで破ったもの」。

私の経験から、テストを見逃したり、「低グレードのコード」と見なしたりしないでください。そして、私の答えは、長期的には目に見える結果しか得られない方法論の変更を指摘していますが、将来的には問題を完全に回避するのに役立つ可能性があります。

于 2013-01-07T09:11:15.583 に答える
2

質問を正しく読めば、ソース コードを分析し、どのテストを再実行する必要がないかを判断するツールが必要になります。

最初に考慮すべきことは、常にすべてのテストを実行することの問題は何ですか? それがCIの意味です。すべての単体テストを 15 分間で実行できず、すべての統合/ストレス テストを一晩で実行できない場合は、おそらくハードウェアを購入して、その原因となっている問題を解決してください。

それができない場合、潜在的なテスト リグレッションを追跡できる唯一のものはカバレッジ分析です (例: http://www.eclemma.org/ )。基本的な OO 設計であっても、依存性注入は言うまでもなく、静的パッケージまたはクラスの依存性はせいぜい無意味であり、どの変更がどのテストを失敗させる可能性があるかという点で、おそらく積極的に誤解を招くものです。そして、問題が A が B を呼び出すべきであり、そうでないというケースを無視しています。ただし、変更されたファイルと呼び出されたファイルを相互参照し、交差がない場合は、おそらくテストを再実行しない方が安全です。残りの失敗は、以前にはなかったイベント ハンドラーを追加するコードのようなものです。

これを行う無料のツールはないと思いますが、Jenkins/Emma/Git からスクリプト化できるはずです。または、Kalistick などの統合ソリューションのいずれかを使用します。しかし、開発チームが何をしようとしているのかについて、開発チームとのコミュニケーションに基づいて人間の判断を効果的に打ち負かすことができるかどうかは懐疑的です。

漠然と関連するメモとして、Java の世界が実際に必要としているが存在しないというシンプルなツールは、一連のテストを依存関係の順序で実行し、最初のエラーで停止する junit の拡張機能です。これは、開発者が回帰の最も可能性の高い原因に集中できるようにするための追加の助けとなります。

于 2013-01-04T13:00:11.703 に答える
2

私は Sonar の大ファンです。あなたはすでに Sonar を実行していて、CI 環境で作業しているので、それが私の提案です。Sonar の Dependency Cycle Matrix が、あなたが望むこと、またはそれに加えてあなたが望むことをまだ行っていない理由がよくわかりません。

于 2013-01-04T08:52:12.047 に答える
2

Classycle-Dependency Checkerを使用して、クラス レベルまでの依存関係を見つけることができます。また、ガイドの「クラスの依存関係を確認する」セクションがあなたのケースに役立つかもしれません。ただし、通常、静的分析ツールを使用して、ソース コードベース (例: Project->src ディレクトリ) またはテスト コードベース (例: Project->test ディレクトリ) のいずれかを分析しますが、両方は分析しません。しかし、あなたの場合、ソース コードとテスト コードの間の依存関係も調べたいようです。そのため、src と test の両方の親パス (例: プロジェクトのルート ディレクトリ) として入力パスを提供することにより、適切な依存関係分析ツールを実行することが必要な場合があります (例: 依存関係を使用して見つける -> ソース X が変更された場合、テストの依存クラスはその変更の影響を受けます)。

于 2013-01-05T17:23:05.417 に答える