私のアプリケーションの単体テストを書いています。クラスのすべてのメソッドをできるだけプライベートなものにしようとしています。メソッド、いくつかのpublicメソッド、時には静的メソッド（他のクラスやTextUtilsなど）を呼び出すことがあります。単体テストのJavaでのプライベートメソッドと静的メソッド
私はすべてのクラスをテストする方法を知っています.MockitoとRobolectricとPowermockitoは単体テストで何をすべきかの境界を広げているようだから、JUnit。私はすべてのプライベートメソッドと静的メソッドを無視して、偶然にいくつかの静的メソッドまたはプライベートメソッドを呼び出すpublicメソッドと一緒に使うべきですか？またはどのように？
テストしているクラスのすべてのプライベートメソッドは、public/protected/packageプライベートメソッドによって呼び出される必要があります。さもなければ、それらは未使用のコードです。だから、あなたのアプリの "クライアントコード"に見えるこのパブリックAPIをテストすることに集中してください。内部（プライベートメソッド）は、APIが指定する公開契約を実際に実装するため、副作用としてテスト/カバーされます。
実装の詳細（プライベートメソッド）を直接テストすると、テストを保守しにくくし、テスト対象コードをリファクタリングするのが難しくなります。
答えをありがとう。私は実際にそれについて考えましたが、それは私の頭の中で何らかの形で間違っていました。なぜなら私も私的なものを呼び出す公的方法を持っていて、私はそれらを捕まえるために前者をテストします。アンサンブル " – kioli
ユニットテストの"ユニット "は必ずしも簡単に定義することができません。しかし、一般的には、クラスのパブリックインターフェイスのテストに焦点を当て、実装の詳細をうまくカプセル化しておくと、長期的にはもっと簡単になると思います。プライベートメソッドがあなたが具体的にテストしたいことをやっていると感じるならば、おそらく、このロジックはそれ自身のクラスでモデル化されなければならないことを意味します。 –
@kioli * "私はもう"ユニット "をテストするのではなく、"アンサンブル "" ** ** - **ここでの質問は**ユニット**とは何ですか？*私はRoy Osheroveの定義が気に入っています：*ユニットとは、変更するのと同じ理由のあるコードの集まりです。*これはユニットが単一のメソッドか2つのクラスになることを意味します。 –
注：これは一般的な情報です。あなたの質問にコメントするコードはありません。
プライベートメソッドは一般的にクラス外ではアクセスできません（リフレクションは別の問題です）。通常、パブリックメソッドと保護されたメソッドに機能を提供するために、単体テストで公開メソッドと保護メソッドをテストする必要があります。テストデータを慎重に選択した場合は、コードのほとんどまたはすべてを実行できるはずです。
Mockitoを使用すると、テスト対象のクラスに必要なすべての依存関係をモックアウトできます。外部機能を模擬するか、またはテスト対象のクラスが期待どおりに発信呼び出しを行うかどうかを確認するには、期待値（Mockito.when(...).thenReturn(...)またはMockito.verify(mockedClass).method(...)）を使用します。
アサーションを使用して、テストされているメソッドが適切な値を返すことを確認できます。
しかし、高いコードカバレッジの詳細な単体テストは、テスト対象のクラスの内部実装を初めて変更しようとする可能性が高いことに注意してください。それはバランスの取れた行為であり、テストの脆弱性を最小限に抑えながら適切なレベルのカバレッジを見つける必要があります。
答えをありがとう、私はなぜ私は直接プライベートメソッドのテストをスキップするのが間違っているかもしれないと思った上記の答えにコメントしました – kioli
これは2つの非常に異なる質問です。一般に、プライベートメンバーはパブリックインターフェイスを介して間接的にテストされ、静的メソッドは通常スタンドアロンでテスト可能です。 – chrylis
ありがとう@chrylis – kioli