基本クラスのテストを回避しても大丈夫ですか？

かなり汎用的である必要がある柔軟性/抽象化を与えるために、かなりの量の「メタプログラミング」を持つ基本クラスがあります。

基本クラスの共通メソッドを使用するサブクラスが多数あり、各サブクラスのすべてのケースをカバーする動作指向の単体テストがあります。

基本クラスのテストをスキップしても大丈夫ですか？

十分なテストがあるかどうかを確認するために、コードカバレッジとテストによって引き起こされたブランチカバレッジを確認できます（おそらく、カバレッジツールを使用するか、コードパスを確認するか、デバッガーを使用して手動で）。

結論が出ると、サブクラスのテストでベースクラスのコードを十分にカバーできるので、テストを追加しても大きなメリットは得られません。一方、ベースクラスを直接使用して特定のテストを追加することによってのみテストできるコードパスがある場合は、このルートを使用する必要があります。

「基本クラスを直接テストする」理由として考えられるもう1つの理由は、そのクラスの特定の機能を「分離して」テストすることです。特定のメソッドを使用するサブクラスのメソッドを呼び出して間接的にそのメソッドをテストするだけでなく、特定のメソッドのテストケースを直接設計する方が簡単な場合があります。

一般的な使用シナリオでサブクラスを派生させる汎用ベースクラスがある場合、基本クラスはおそらく抽象クラスであることに注意してください。したがって、このようなクラスをテストするには、とにかく派生を行う必要があります。この状況では、「基本クラスを直接」テストすることは、もちろんテスト目的のためだけに特別な派生物を追加することを意味します。

自動化されたテストはプログラマーの利益のために作成されたものであり、プログラマーはテストを提供するために作成されたものではありません。

生産性を高め、顧客が不満を抱く「問題」の数を減らすためのテストがあります。

したがって、各サブクラスのすべてのケースをカバーする動作指向のユニットテストがある場合、ベースクラスを直接テストすることもお客様にとってメリットはありません。これは、基本クラスの一部のコードを変更し、テストが失敗するかどうかを確認することで確認できます。たとえば、コード行を共通化するか、「ifステートメント」に「not」を追加します。（すべてのコード行がテストでカバーされていることを確認するだけでは十分ではありません。）

テストがより生産的になるかどうか尋ねることになります。これにはいくつかの方法があります。

• コードについてより明確に考えさせてください-コードが書かれているので、この場合はこれはほとんどありません。
• 基本クラスの一部のコードを単独でテストできるようにするため、コードが既に動作している場合には再び起こりそうもない、より迅速にデバッグします。
• サブクラスのロジックの詳細を理解しなくても、基本クラスのコードを変更できます-コードをリファクタリングしている場合は？

したがって、サブクラスが機能していることを考えると、基本クラスの直接テストを作成しても意味がありません。 これは今日ではありません。初期の状態でこれらのテストを書くことには利点がなかったでしょう。