JUnit 4とTestNG-2013-2014の更新[終了]

JUnit 4とTestNGは比較可能でした。2つのテストフレームワークの長所と短所は何ですか？

今日はTestNGとJUnit4を比較していましたが、testing-frameworksの限られた経験で指摘できる主な利点は、TestNGがデータプロバイダーの概念を使用してパラメーター化されたテストを処理するよりエレガントな方法であることです。

JUnit4でわかる限り、テストする（で実行する@RunWith(Parameterized.class)）パラメーターのセットごとに個別のテストクラスを作成する必要があります。TestNGでは、1つのテストクラスに複数のデータプロバイダーを含めることができるため、1つのクラスのすべてのテストを1つのテストクラスに保持することもできます。

これまでのところ、JUnit4よりもTestNGの利点として指摘できるのはそれだけです。

Intellij IDEAには、そのままでTestNGおよびJUnitのサポートが含まれています。ただし、EclipseはデフォルトでJUnitのみをサポートしており、動作させるにはTestNGプラグインをインストールする必要があります。

ただし、TestNGで遭遇したさらに厄介な問題PowerMockTestCaseは、PowerMockを使用してテストの依存関係をモックする場合、テストクラスを拡張する必要があることです。どうやら、PowerMockを使用するときにテストフレームワークが知っておく必要があるオブジェクトファクトリを特別な方法またはtestng.xmlスイート定義で構成する方法はいくつかありますが、現時点では壊れているようです。私はテストクラスがテストフレームワーククラスを拡張するのが嫌いです、それはハックのようです。

PowerMockを使用しない場合、これはもちろん問題ではありませんが、全体としては、JUnit4がより適切にサポートされているという印象を受けます。

両方のフレームワークでの私の経験に基づくと、testngには、JUnitチームが数年間実装を拒否した便利な機能がいくつかあります。このため、JUnitよりも好みます。testngへの変換は基本的にJUnitのほとんどすべてをサポートしているため（Eclipseのコンバータープラグインさえあります）、JUnitに変換し直すことは、これらの機能が不足しているためそれほどうまくいきません。

• testngの@BeforeClassメソッドは静的ではなく、テストクラスがロードされるとき（JUnitの動作）ではなく、そのクラスのテストが実行される前に実行されます。私はかつて、すべてのデータベーステスト（数十）が最初からデータベースを初期化するJUnitプロジェクトを持っていましたが、これはかなりばかげた動作でした。JUnitコミュニティでは、これについて賛否両論があります。その要点は、すべてのテストメソッドに独自のテストフィクスチャが必要であり、したがって、インスタンス変数を一度こっそり設定してすべてのテストで使用できるようにするため、静的ではないbeforeAllスタイルメソッドを使用するべきではないということです。有効ですが、統合テストには本当に面倒です。TestNGはここでユーザーに選択肢を提供します。Junitは設計上、煩わしくありません。

• Testngデータプロバイダーは、JUnitの同等のものよりも少し柔軟性があります。JUnitのように1つのサイズがクラス全体のすべてのアプローチに適合するのではなく、テストごとにどのデータプロバイダーメソッドが入力を提供するかを指定できます。したがって、1つのクラスでテストのポジティブおよびネガティブケースのデータプロバイダーを持つことができます。とても素敵です。

• @Testin testngでクラスをマークアップできます。つまり、すべてのパブリックメソッドはテストです。JUnitでは@Test、すべてのメソッドにコピー/貼り付けする必要があります。

両方の問題は、hamcrestがJUnitにバンドルされている方法と、JUnitがtestngにバンドルされている方法です。Mavenには、この問題がない代替のjarファイルがあります。

両方のフレームワークに関する私の大きな心配は、どちらも進化しなくなったように見えることです。リリースの頻度はますます少なくなり、注目すべき機能はますます少なくなります。たとえば、BDD全体の動きは、どちらのフレームワークにもほとんど影響を与えていなかったようです。また、JUnitは、上にリストしたもののほとんどを単純に採用することができます。JUnitがこれらのいずれも実装できないという技術的な理由はありません。JUnitの背後にいる人々は、これらのものを実装しないことを選択します。どちらのプロジェクトも、将来の方向性についてのビジョンが欠けているようであり、過去数年間、ほんのわずかな調整を行って満足しているようです。

私はJUnitの上でTestNGのを切り替えるには十分な理由を探していたし、私が見つかりました。この Tomek Kaczanowskiによってスライドが非常によく、この質問に取り組みます。Tomekは、開発者やテスターから非常に尊敬されているように見える実用的なユニットテストの本の著者です。

Java / Scalaプロジェクトで作業していて、Gradleが選択したビルドツールである場合、ScalaTestフレームワークはScala JUnitRunnerテストを実行するだけでよいことに注意してください。つまり、選択肢は次のとおりです。

• Java JUnitテスト+ JUnitRunnerで実行されるScalaテスト=>より優れたGradle統合
• Java testNGテスト+ Scalaテストは、Scala Runner => Poor Gradle Integrationで実行されます。これは、ScalaテストランナーがGradleの観点からは単一のバルクタスクであるためです。

Mockitoをモックフレームワークとして使用できます。TestNGとうまく統合されます。MockitoをTestNGで使用するためにクラスを拡張する必要はありません。この方法でテストするコードはそれほど結合されていないため、何らかの理由で他のモックフレームワークを使用する必要がある場合は、簡単に実行できます。

一言で言えば..

スコープが依存関係のない詳細な単体テストに限定されている場合は、JUnitを使用できます。

スコープで機能テストが必要な場合は、テスト間の依存関係とデータ（パラメーター）の共有が必要な場合と必要ない場合があります。その場合、TestNGを選択します。また、TestNGはJUnitと同様のユニットテストを実行できます。つまり、単体テストのスイートと機能テストのスイートを持つことができます。