内部クラスをユニットテストする必要がありますか？

Question

私たちは職場で新しいAPIを開発しています。私の同僚と私は内部クラスがユニットテストされるべきかどうかに関して異なった意見を持っています。ユニットテストを含め、あなたの完全なコードをカバーすることができるはずパブリッククラス/メソッドに対してのみ

を書かれるべき内部クラス

1. をテストないユニットのために私の同僚で与え

   ポイントパブリックAPI自体を介した内部クラス内部クラスがパブリックインターフェイス経由でテストされていない場合、テストケースが見つからないか、不要なコードが見つかったことを意味します。

2. 内部クラスの単体テストを記述すると、重複したテストが行​​われたり、必要のないコードを強制的に作成することがあります。ユニットテストを通じて完全なコードをカバーの内部クラス
   1. のテストユニットの賛成で私が与え

   ポイントが唯一の公共のクラスは非現実的/難しいかもしれません。内部クラスの単体テストを書くことは、少なくとも自分の世界で正しく動作することを保証し、アプリケーション全体の正確性をテストするために統合テストを行うことができます。

3. ユニットテストに冗長性がある場合でも、トップレベルにテストケースがない場合よりも優れています。
4. 内部クラスは周囲に公開されているため、それらを個別にテストする必要があります。パブリッククラスが1つと内部クラスが100つしかない場合は、パブリックインターフェイスを介してすべてのシナリオをカバーすることは非常に困難です。

オンラインで検索しましたが、これに関するベストプラクティスや標準的な意見はないようです。何が良いアプローチであると思いますか？ Javaの人々に

注：「内部は、」アセンブリへのクラスの可視性を制限し、C＃でのキーワードです。クラスはパッケージ/アセンブリの外部からアクセスできません。プライベートクラスと同等ではありません。

Answer 1

これはケースバイケース決定されるべきである：

• あなたは共有機能提供ユニットテストの内部クラス必要があります - あなたのライブラリ内の一部のクラスは、共有コードのための場所を提供しています。クラスを使用して間接的にテストされますが、追加の直接テストでは、クラス自体の問題とクラスの使用の問題を区別できます。
• 個人的にネストされる可能性のある内部クラスを単体テストすることは避けてください。 - 一部のクラスは、単一のクラスまたは単一のクラス階層の実装ロジックを提供します。そのようなクラスはネストされたクラスに変換できますが、審美的または哲学的な理由からトップレベルのクラスとして保持されます。これらのクラスは、それらを使用するクラスのパブリックインターフェイスを介してテストする必要があります。

ユニットテストの共有実装は、共有コードをリファクタリングする必要がある場合に特に役立ちます。壊れた変更を行い、すべての単体テストが他のクラスを介して間接的に実行された場合、根本的な原因を指していない複数の単体テストの失敗が発生します。一方、共有実装のための直接的な単体テストがある場合、根本的な原因をより簡単に検出できます。

さらに、クラス自体の直接テストがあるので、内部クラスのコードの範囲を失うことはありません。

あなたの議論は、第1の箇条書きのクラス（共有実装）のクラスに適用され、同僚の議論は第2の箇条書きのクラス（私的実装）に適用されます。