いくつかのプライベートメソッドを使用してクラスを単体テストしようとしています。それぞれのプライベートメソッドはかなり広範囲に及ぶ可能性があります。
メソッドパッケージのスコープを設定するか（警告が発生します）、以下のコードを使用してテストできます。
Method method = instance.getClass().getDeclaredMethod("methodName");
method.setAccessible(true);
Object object = method.invoke(instance);
assertNotNull(object);
クラスは「神オブジェクト」ではなく、そのメソッドのほとんどはそのすべてのフィールドにアクセスします。
これをより適切に処理する方法について何か提案はありますか？
プライベートメソッドをテストすることも、テストの匂いである可能性があります。
私の参考書は素晴らしい本ですhttp://www.manning.com/rainsberger/
メソッドの代わりに動作をテストすることになっています。粒度は少し異なります。
例1：パイルをテストするには、相互に参照せずにどのようにテスト
pushしますか？popただし、グローバルな動作をテストすることは可能です。これは、テストの場合でも、オブジェクトはメソッドではなく、適切な粒度であることを思い出させます。例2：複数のオブジェクト間の相互作用をテストする場合、メソッドごとのテストは明らかに正しくありません。グローバルな動作をテストする必要があります。
メソッドが公開されていない場合、外部から呼び出すことはできず、その動作はそれほど厳密には定義されていません。しかし、何よりも、プライベートメソッドをテストすると、後でコードをリファクタリングすることができなくなります。したがって、テストはパブリックコードでのみ実行する必要があります。
KLEは正しいです。
ただし、レガシーコードを使用していて、プライベートメソッドの依存関係を処理する必要がある場合、最後の選択肢の1つはJMockitです。私はそれを使用していませんが、 The Art ofUnitTestingでそれについて読んでいます。元のクラスから偽のクラスへの呼び出しを交換できるはずです。
これを使用して、他のオブジェクトへの依存関係を解消し、プライベートメソッドをテストするのではなく、パブリックメソッドをテストできるようにします。そして、分離された設計へのリファクタリングに向けた途中のセーフティネットとしてそれを使用してください。
まだ使用していない場合、これはおそらく一筋縄ではいきません...しかし、Groovyは、単体テストのアクセス制限に違反するのに非常に優れています...追加の反省なしに、メソッドにアクセスして、パブリックであるかのように呼び出すことができます。
スコープメソッドをパッケージ化するときにどのような警告が表示されるのか知りたいのですが、とにかく、この種の問題を回避する方法は、テストをオブジェクトの静的内部クラスにすることです。これにはトレードオフがあります。デプロイメントサイズが重要な問題である場合は、クラスをコードと一緒にパッケージ化することから除外する必要があります。また、テストフレームワークから本番コードに誤って依存関係を導入することに注意する必要があります。
もう1つの潜在的なオプションは、必要なメソッドを公開するのに役立つ静的内部クラスを用意することです。テストでは、それをプライベートメソッドへのパススルーとして使用します。ここでの欠点は、このクラスが基本的にクラスを使用したいすべての人にプライベートメソッドを公開することです。したがって、このクラスがテスト目的のみであることを明確に表現するように注意する必要があります。
リフレクションの使用を検討してください。