スーパークラスから継承されたメソッドを単体テストする必要がありますか？

Question

現在、TDDの方法でJDBCドライバーの実装を記述しています（はい、正しく読みます）が、この時点でクラススタブのみを終了し、いくつかのマイナーな機能のみを使用していますが、 Statement は CallableStatement のスーパークラスである PreparedStatement のスーパークラスであるため、実際に開始したらどうすればよいかがわかりました。これらのクラスの実装用のテストを作成します。これらのいずれかを実行する必要があります。

1. Statement のテストスイートを作成し、 PreparedStatement の追加テスト用にそのスイートを拡張してから、 CallableStatement に対して同じことを行います。
2. スーパークラスから継承されたメソッドを無視して、各実装を個別にテストします。
3. 実装クラスごとに個別にすべてのメソッドを厳密にテストします。いくつかの継承されたメソッドは、実装によって結局異なる動作をする可能性があります。これの穏やかなバリエーションは、実装が使用するすべての継承されたメソッドをテストすることです。

ナンバー2は最も自然な感じがしますが、3番目に置く理由から、そうするのが賢明かどうかはわかりません。それでは、あなたは何をすべきだと思いますか？

Answer 1

これは、テストサブクラスごとに同じテストを繰り返し実行することを意味する場合、具体的には代替1（テストクラス階層を実際のクラス階層と同じにする）を実行しません。また、一般的なユーティリティベースクラス以外のテストクラスをサブクラス化することにも、一般的に懐疑的です。

通常、抽象的であるかどうかにかかわらず、階層内の各クラスに対して1つのテストを行います。そのため、基本クラスには個別のテストがあり（通常は、テスト専用のテストローカルプライベートサブクラスを使用）、サブクラスの知識を使用して、各サブクラスに適切なテストを記述します。カバレッジでは、欠落しているテストが実行されていることがわかります。そのため、通常、事前に形式化されていません。

Answer 2

＆quot;実装クラスごとに個別のすべてのメソッドをテストする＆quot;

特に、スーパークラスメソッドを適切にオーバーライドできないことはよくあるバグです。サブクラスの作成者は、スーパークラスについて想定しています。スーパークラスが変更され、サブクラスが壊れています。

Answer 3

実装の知識に基づいて、快適に感じるように十分なテストを提供します。私はユニットテストを完全にブラックボックステストとして扱っていません。基本クラスが仮想メソッドを一切呼び出さない（または少なくともオーバーライドされない）ことがわかっている場合は、その事実に注意してください。ただし、既に取得している単体テストを効果的に複製しないでください。

単体テストは確かに極端なものにすることができます-そこから得られる価値と、それが負担となる努力とのバランスを取ることは常に価値があります。

Answer 4

TDDを使用すると、メソッドのテストではなく、コードの動作または機能をテストする必要があります。したがって、サブクラスを実装する場合、基本クラスとは異なる動作のみのテストに制限できます。疑わしい場合は、新しいテストを作成します。