java - プロジェクトにおける JUnit テストの編成

Question

プロジェクトで JUnit テストを編成するためのベスト プラクティスは何だと思いますか。また、その理由は何ですか? たとえば、テストをテストするクラスの隣に置いていますか? それらを別々の並列パッケージ構造に入れますか? まったく別の組織戦略を使用していますか?

Answer 1

いくつかの理由から、私は個別の並列パッケージ構造を使用しています。

1. アプリケーションコードと同じようにテストを整理します。
2. 配布用のアプリケーション ファイルだけを簡単にビルドできます。
3. テスト コードは引き続きアプリケーション コードにアクセスできます。
4. テスト コードとアプリケーション コードを混在させるほど雑然としていません。

Answer 2

私は自分のテストを別の類似/並列パッケージ構造に入れました。これが Maven の好みであり、IDE でもうまく機能します。テスト コードがアプリケーション コードと混同されていないため、この方法が気に入っていますが、モックと状態検証の目的でパッケージ プライベートなものにアクセスすることもできます。

Answer 3

Mavenを使用するだけです。Maven を使用すると、プロジェクトのデフォルト構造を作成できます。

mvn archetype:create -DgroupId=com.yoyodyne -DartifactId=UberApp

これにより、単体テストとメイン プロジェクト用のスペースを含むMaven の標準ディレクトリ レイアウトが作成されます。Maven を使用すると、単体テストを jar にパッケージ化せずに実行でき、アプリケーションだけを含む jar を構築できます。実行時、テスト時、コンパイル時に異なるクラスパスと異なる依存関係を持つこともできます。

ここら辺で実際に Maven を使っている人がほとんどいないことは非常に気がかりです (少なくとも Ant ですが、依存関係の処理には Maven の方が好きです)。

Answer 4

プロジェクトでMavenを使用しない場合でも、Mavenプロジェクトの構造を尊重します。これは、それに慣れているからです。ベストプラクティスは、メインのソースフォルダと同じパッケージ構造を尊重する別のソースフォルダを使用することです。

テスト固有のソース（テストでのみ使用するためにコーディングするユーティリティ）をそこに配置する必要があります。アプリのランタイムコードでそれらを使用する場合は、メインのソースフォルダーに移動します。アイデアは、たとえば、永続性と制御を分離することによって効率を因数分解するのと同じように、うまく分離することです。

Answer 5

トカゲのビルが言ったように、

1) src.zip または src.tar.gz を出荷し、単体テストを省略することができるように、並列構造を持つことが役立ちます。 2) バージョン管理システム レベルで、誰がソース コードを変更し、誰が変更したかについてフックを配置できます。単体テストのみを変更します

"短所"
ソースと単体テストの両方が同じパッケージにある場合、JAR ファイルを封印できません (つまり、.JAR を準備して封印する前に、単体テストを削除する必要があります)。