私は多くのプロジェクトに取り組んでおり、CI に Java、Springs、Maven、および Jenkins を使用していますが、一部のプログラマーが実際の junit テスト ケースをプロジェクトに追加していないという問題に直面しています。サーバーにデプロイする前に、maven と jenkins にテストを実行してもらいたい。一部のプログラマーは、空のテストを作成して、テストを開始および停止し、テストに合格するようにしました。
誰かがこのチェックを自動化して、テストが何らかの出力を出したかどうかをmavenとjenkinsが確認できるようにする方法を教えてください。
コードを確認する以外に、この問題に対する適切な解決策は見つかりませんでした。
コードカバレッジは、私が今まで見た中で最悪の単体テストを検出できません
テストの数を見ると、そこでも失敗します。テスト名を見ると、失敗するに違いありません。
そのようなテストを作成する「Kevin」のような開発者がいる場合は、コードレビューによってのみそれらのテストをキャッチします。
「ケビン」がどのように小切手を打ち負かすかの要約：
と呼ばれるテストを作成しsmokesます。このテストでは、パラメーターのさまざまな組み合わせを使用して、テスト対象のクラスのすべてのメソッドを呼び出します。各呼び出しはでラップされtry { ... } catch (Throwable t) {/* ignore */}ます。これにより、優れたカバレッジが得られ、テストが失敗することはありません
派手なテストシナリオを考えたように聞こえる名前で、空のテストをたくさん書いてwidgetsTurnRedWhenFlangeIsOffくださいwidgetsCounterrotateIfFangeGreaterThan50。これらは空のテストであるため、失敗することはありません。CIシステムを検査するマネージャーは、多くの詳細なテストケースを確認します。
コードレビューは「ケビン」を捕まえる唯一の方法です。
開発者がそれほど悪くないことを願っています
今朝はにわか雨が降った。「ケビン」を捕まえることができる自動分析のタイプがありますが、残念ながらそれはまだだまされている可能性があるため、悪いテストを書く人にとっては解決策ではありませんが、悪いテストを書くのは難しくなります。
これは古いプロジェクトであり、最近のコードでは機能しません。これを使用することはお勧めしません。しかし、私はそれが「ケビン」を止める一種の自動分析を示唆していることを示唆しています
これを実装する場合、ASMなどを使用してバイトコードを一度に1つの小さな「jest」で書き換える「JestingClassLoader」を作成します。次に、このクラスローダーをロードしたときに、クラスに対してテストスイートを実行します。テストが失敗しない場合、あなたは「ケビン」の土地にいます。問題は、コード内のすべての分岐点に対してすべてのテストを実行する必要があることです。ただし、自動カバレッジ分析とテスト時間プロファイリングを使用して、処理を高速化することもできます。つまり、各テストが実行するコードパスを知っているので、1つの特定のパスに対して「冗談」を言うと、そのパスにヒットしたテストのみを実行し、最速のテストから開始します。これらのテストのいずれも失敗しない場合は、テストカバレッジに弱点があります。
したがって、誰かがJesterを「近代化」した場合、「Kevin」を見つける方法があります。
しかし、それは人々が悪いテストを書くのを止めることはありません。コードが現在の動作、バグなどすべての動作を検証するテストを作成することで、このチェックに合格できるためです。「あなたのためにテストを書く」ソフトウェアを販売している会社さえあります。ここからリンクしてGoogleページランクを与えることはしませんが、彼らがそのようなソフトウェアを手に入れれば、コードベースを拘束するテストがたくさんあり、バグは見つかりません（何かを変更するとすぐに「生成された」テストは失敗するため、変更を行うには、変更自体と、変更が壊れたすべての単体テストへの変更について議論する必要があり、変更を行うためのビジネスコストが増加します。その変更は実際のバグを修正しています）
非常に便利なビルド ブレーカープラグインを備えたSonarを使用することをお勧めします。
Sonar品質プロファイル内で、メトリクスの任意の組み合わせに対してアラートを設定できます。たとえば、Java プロジェクトに
開発者に、コードベースの最低 20% をカバーする少なくとも 1 つの単体テストを実施するように強制します。（かなり低品質のバーですが、それがあなたのポイントだと思います！）
追加のサーバーのセットアップは余分な作業のように見えるかもしれませんが、複数の Maven プロジェクトがある場合、ソリューションは拡張されます。Sonar 用のJenkins プラグインを設定するだけで十分です。Jacoco はデフォルトのコード カバレッジ ツールであり、Sonar は Checkstyle、PMD、Findbugs などの他のツールも自動的に実行します。
最後に、Stephen はコード レビューに関して完全に正しいです。Sonar には、基本的ではあるが便利なコード レビュー機能がいくつかあります。
http://pitest.org/は、いわゆる「変異テスト」に適したソリューションです。
障害 (または突然変異) は自動的にコードにシードされ、テストが実行されます。テストが失敗した場合、ミューテーションは強制終了され、テストがパスした場合、ミューテーションは存続します。
テストの質は、殺されたミューテーションのパーセンテージから測定できます。
良いことは、maven、jenkins、および... SonarQubeと組み合わせて簡単に使用できることです!
JaCoCo、EMMA、Cobertura などのコード カバレッジ プラグインを追加する必要があります。次に、プラグインの構成で、ビルドが成功するために必要なコード カバレッジ (基本的には「テストでカバーされるコード」) の割合を定義する必要があります。その数を下回ると、ビルドが失敗する可能性があります。そして、ビルドが失敗した場合、Jenkins (または CI が何であれ) はデプロイされません。
他の人が指摘しているように、あなたのプログラマーがすでにコーディング手法をごまかしているのであれば、より優れたカバレッジ ツールを使用しても問題は解決しません。彼らもだまされる可能性があります。
チームと一緒に座って、プロフェッショナリズムとソフトウェア エンジニアリングのあり方について率直に話し合う必要があります。
私の経験では、コード レビューは素晴らしいものですが、コードがコミットされる前に行う必要があります。しかし、人々が「ごまかしている」プロジェクトでそれが機能するためには、少なくとも信頼できるレビュアーが必要です。