0

テストされたメソッドと同じクラスで単体テストを作成することと、（同じパッケージまたはexternパッケージの）別のクラスで単体テストを作成することの違いは何ですか？これらのテスト場所の長所または短所は何ですか？

4

6 に答える 6

4

別のクラスでテストを行う場合は、次のことができます。

  • よく知られている単体テストフレームワークを使用すると、作業がずっと楽になります。私が知っているすべてのフレームワークは、テストをテスト済みのコードから分離しておくことを前提としています。
  • 必要な数のテストケースを用意します（本番クラスを巨大で管理しにくくすることなく、適切に管理されたプロジェクトには、本番コードとほぼ同じ数の単体テストコードがあり、おそらく本番よりもはるかに多くの公開テストメソッドがあることに注意してくださいAPIメソッド。最終的にはIDEのAPIインデクサーを駆動し、その後は自分自身を駆動する可能性があります...）
  • テストなしで本番コードを出荷します-テストの依存関係も含みます（テストにのみ使用されるサードパーティのものを製品展開バンドルにバンドルすることを好む人は誰もいませんよね？）
  • 本番コード自体に触れることなくテストを変更します（これにより、本番コード/データの変更をテストの変更から分離することが常に簡単になるため、SCMでの監査と変更管理がはるかに簡単になります）
于 2012-05-09T14:52:35.327 に答える
1

ベストプラクティスは、検証しているコードとは別のテストです。理由は単純です。アプリケーションにテストをパッケージ化する必要はありません。アプリケーションはクリーンである必要があります。テストでは、外部から機能を検証する必要があります。

多くの場合、テストには追加の依存関係があります（たとえば、テストフレームワーク、モックアップライブラリなど）。

一般的な方法は、ソースコードを下に置きsrc/main/java、テストを下に置くことsrc/tests/javaです。

于 2012-05-09T14:54:03.647 に答える
0

分離されたクラスで記述することの利点は、テストをコードから分離できることです。たとえば、mavenの場合：
1。すべてをビルドします
2.以下を含むクラスを実行します**/*Test*.java pattern

コードと同じクラスでユニットテストを行う方法すらわかりません...

于 2012-05-09T14:51:59.140 に答える
0

コードをテストするためのテストメソッドがあります。それらをテスト済みのクラスに入れると、クラスのAPIが乱雑になり、クラスのバイトコードと依存関係が必要以上に大きくなります。

電卓クラスを使用したい場合は、テストメソッドは必要ありませtestPlusWorks()んtestMinusWorks()。plus()私はただ必要minus()です。またtestPlusWorks、JUnitまたはMockitoライブラリのクラスに依存している場合、これらの依存関係は本番環境では必要ありません。これらは、クラスをテストする場合にのみ役立ちます。

于 2012-05-09T14:53:39.393 に答える
0

この質問に対する「正しい」答えはありません。

同じクラスでの記述：プライベートメソッドをテストできますが、コードが台無しになります。

同じプロジェクトでの書き込み：内部メソッド/ロジックをテストできますが、プロジェクトが台無しになり、コンパイル時間が長くなります。

外部への書き込み：プロジェクトの内部メソッド/クラスをテストできなくなりますが、テストはクリーンで「本番」コーダーの外部に保持されます。

于 2012-05-09T14:53:55.667 に答える
0

ユニットテストはまったく別のソースフォルダーに作成するのが最善だと思いますが、packaged（デフォルト）スコープのメソッドとvarialbleにアクセスできるので、同じパッケージに保持してください。

  1. これにより、テストがまとめられ、ナビゲーションと健全性が容易になります。
  2. ビルドを行うときは、jar / war/earのテストクラスを除外できます。
于 2012-05-09T14:54:16.347 に答える