3

チーム リーダーの問題の 1 つは、チームのメンバー (時には私自身も含む) が、テスト機能なしで JUnit テストを作成することがよくあることです。

開発者は JUnit テストをハーネスとして使用して、コーディングしているアプリケーションの一部を起動し、意図的または忘れてアサート テストやモック検証なしでチェックインするだけなので、簡単に実行できます。

その後、テストが不完全であることを忘れてしまいますが、テストは成功し、優れたコード カバレッジが生成されます。アプリケーションを実行してデータをフィードすると、Cobertura または Jacoco から高いコード カバレッジ統計が作成されますが、爆発せずに実行する機能以外は何もテストされていません。テスト。

テストコードを頻繁にレビューする必要がないように、テストをテストするレポートツールはありますか?

テスト中のコード (if 句など) を変更してテストを再実行し、テストが中断されるかどうかを確認することでテストをテストするJesterを見つけて、一時的に興奮しました。

ただし、これは CI サーバーで実行するように設定できるものではありません。コマンド ラインで設定する必要があり、GUI を表示せずに実行することはできず、GUI に結果を出力するだけで、実行には時間がかかります。

4

5 に答える 5

2

可能な限り、機能を実装する前、またはテストで対処することになっているバグを修正する前に、各テストを記述します。機能またはバグ修正の順序は次のようになります。

  1. テストを書きます。
  2. それを実行します。この時点で、良いテストであれば失敗します。失敗しない場合は、変更、交換、または追加してください。
  3. テストに失敗した場合は、テストするはずの機能を実装します。これで合格するはずです。
于 2015-06-04T13:27:42.660 に答える
2

さまざまなオプションがあります。

  • おそらく、checkstyle などのコード分析ツールを使用して、各テストにアサーションがあることを確認できます。または、代わりに JUnit ルールを使用してこれを確認しますが、どちらも簡単にだまされ、表面的なレベルでしか機能しません。

  • Jester のようなミューテーション テストは、やはり機能する技術的なソリューションであり、@Tom_G には機能する可能性のあるツールがあるようです。しかし、これらのツールは (私の経験では) 非常に低速です。これは、コードの変更、テストの実行、結果の分析が何度も繰り返されるためです。そのため、小さなコード ベースでも多くの時間がかかり、実際のプロジェクトでそれを使用することは考えられません。

  • コード レビュー: このような悪いテストは、コード レビューで簡単に発見できます。とにかく、すべての開発プロセスの一部に含める必要があります。

これはすべて、まだ表面に引っかいただけです。熟考すべき大きな問題は、なぜ開発者は、アプリケーションの特定の部分を開始するためだけにコードを作成したくなるのかということです。アプリケーションの一部を起動する必要がほとんどないので、実装したいもののテストを作成しないのはなぜですか。自動化された単体テスト、特に TDD/BDD (つまり、最初にテストを作成するプロセス) のトレーニングを受けてください。

私の経験では、次のようなことを聞​​く可能性が非常に高いです: We can't test this because ....開発者がこれらのテストを作成できない、または作成したくない本当の理由を見つける必要があります。彼らが述べている理由かもしれませんし、そうでないかもしれません。次に、それらの理由を修正すると、テストの嫌悪感は自然になくなります。

于 2015-06-04T14:11:12.530 に答える
0

あなたが探しているのは、確かに突然変異テストです。

ツールのサポートに関しては、非常に効率的で構成可能なメジャー ミューテーション フレームワーク ( Mutation-testing.org )も参照することをお勧めします。Major はコンパイラに統合された mutator を使用し、何を変更してテストするかを細かく制御できます。私の知る限り、Major はまだグラフィカルなレポートを作成していませんが、任意の方法で処理または視覚化できるデータ (csv) ファイルを作成しています。

于 2015-06-05T19:14:08.003 に答える
-1

Jacocoのようなカバレッジ ツールを検討する必要があるように思えますが、 gradleプラグインはカバレッジに関するレポートを提供します。また、EclEmma Eclipse プラグインを使用して同じ結果を得ることができますが、IDE との統合はかなりうまくいきます。

私の経験では、Jacoco は、no-op 単体テストがある場合でも許容できる数値を提供しています。テストされたコードパスを正確に判断できるようです。No-Op テストのカバレッジ スコアは低くまたは 0% になり、テストが完了するにつれてスコアが増加します。

更新 ダウン投票者に対処するため。おそらく、これに対処するためのより適切なツールはPMDです。IDE またはビルド システムで使用できます。適切な構成とルールの開発により、これらの不完全な単体テストを見つけるために使用できます。過去に特定のセキュリティ関連の注釈が欠落しているメソッドを見つけるためにこれを使用しました。

于 2015-06-04T13:57:54.947 に答える