プロジェクトでJUnitとMockitoを使い始めましたが、私がすぐに気づいたのは、プライベートメソッドをpublicに変換してテストクラスは、ひどい解決策です。JUnit：テストするためにすべてのメソッドを公開する方法
時にはパブリックメソッドだけをテストするだけで十分ですが、時には内部メソッドも実際にテストしたいことがあります。このための回避策はありますか？たとえば、JUnitがプライベートメソッドを公開したり、そのようなものを模擬することを可能にする特別な注釈はありますか？
パブリックメソッドはプライベートメソッドを呼び出す必要があります。 パブリックメソッドのテスト機能を使用してプライベートメソッドをテストできます。
まだJunitsによるプライベート機能をテストする場合は、reflectionを使用して実行できます。
あなたはsetAccessible==true.
に例の方法のプロパティを設定する必要があります。getDeclaredMethodあなたがprivateメソッドの名前を与える必要があり、そしてあなたが渡しているargumentsのタイプで
public void testisvalid() throws Exception
{
MyHandler handler = new MyHandler();
Method privateStringMethod = MyHandler.class.getDeclaredMethod("isvalid", Long.class);
privateStringMethod.setAccessible(true);
String = (String) privateStringMethod.invoke(handler, 852l);
assertNotNull(s);
}
を機能を順番に使用します。
IMHO反射は最後の手段でなければなりません。 [ユニットテストでリフレクションを使用するのは悪い習慣ですか？]（http://stackoverflow.com/questions/2811141/is-it-bad-practice-to-use-reflection-in-unit-testing） –
@Peter私はそれが悪い練習であることを知っています。答えの最初の行は、他の解決策を与えます。しかし、私はまだOPはjunitsによって私的な機能をテストしたいと言いました。 – vikiiii
私たちはこれに同意してうれしいです:-)それはあなたの答えから（少なくとも私に）明らかではなかったので、それを言及することが有用だと思った。 –
プライベートメソッドを直接テストする必要があります。うまく設計されたクラスでは、すべての機能はアクセス可能であり、実用的であり、したがってパブリックインターフェイスを介してテスト可能です。
これは通常、クラスが大きすぎると複雑すぎるため、一度に複数の責任を処理しようとしています。これに対する最善の解決策はリファクタリングです：機能のいくつかを別のクラスに抽出します。そこでは、それを公に利用できるようにして、直接的に単体テスト可能にすることができます。
偉大な答え。コード_の行ではなく、_behaviour_のテストに集中すれば、テストクラスがプライベートメソッドを呼び出すことは決してありません。 –
これらのプライベートメソッドは、追加のヘルパークラスのパブリックインターフェイスの一部である可能性があります。この場合、このヘルパークラスをテストし、元のクラスにモックヘルパーを挿入することができます。
これらのプライベートメソッドを保護し、テストするためにのみ保護されていること、サブクラスで呼び出されたりオーバーライドされたりしないことを文書化し、テストクラスを同じこの保護されたメソッドにアクセスできるように、テスト対象のクラスとしてパッケージ化されています。
この場合、Guavaが提供する@VisibleForTestingアノテーションを使用します。
私のMavenビルドインフラストラクチャでは、テストソースには別のディレクトリがありますが、パッケージ構造は同じです。したがって、メソッドがpublicではなくパッケージにアクセス可能であれば十分です。
パブリックにする必要はありません。パッケージを保護します（修飾子なし： "void testFoo（）"）。テストを同じパッケージに入れてください。 –