Должен ли я тестировать методы модуля, унаследованные от суперкласса?

Question

В настоящее время я пишу реализацию драйвера JDBC ( да, вы правильно прочитали ) в стиле TDD, и хотя на этом этапе я только закончил заглушки классов и только некоторые незначительные функциональные возможности, он Мне пришло в голову, что, поскольку Statement является суперклассом для PreparedStatement, который является суперклассом для CallableStatement, что мне делать, когда я действительно начинаю писать тесты для своих реализаций этих классов, какой из них мне следует делать :

1. Создайте набор тестов для Statement, затем расширьте этот набор для дополнительных тестов для PreparedStatement, а затем сделайте то же самое для CallableStatement.
2. Проверять каждую реализацию в отдельности, игнорируя методы, унаследованные от суперкласса (ов).
3. Тщательно протестировать каждый метод отдельно для каждого класса реализации; Возможно, что некоторые унаследованные методы работают по-разному в зависимости от реализации. Небольшая вариация этого состояла бы в том, что я бы протестировал все те унаследованные методы, которые использует реализация.

Номер два кажется самым естественным, но из-за причины, которую я назвал третьей, я не уверен, что было бы разумно сделать это. Итак, что вы думаете, я должен сделать?

Answer 1

«проверить каждый метод отдельно для каждого класса реализации»

В частности, неправильная переопределение метода суперкласса является распространенной ошибкой. Автор подкласса делает предположения о суперклассе. Суперкласс изменяется, и подкласс теперь сломан.

Answer 2

Я бы специально никогда не делал альтернативу 1 (позволяя иерархии тестовых классов быть такой же, как и реальная иерархия классов), если это означает, что вы будете неоднократно выполнять одни и те же тесты для каждого подкласса теста. Я также скептически отношусь к подклассам тестовых классов, кроме общего базового класса полезности.

Обычно я делаю 1 тест для каждого класса в иерархии, абстрактный или нет. Таким образом, базовый класс имеет отдельный тест (обычно с тестовым локальным частным подклассом, который используется для его конкретного тестирования), и я использую свои знания о подклассах, чтобы написать надлежащие тесты для каждого подкласса. В прогонах освещения я вижу, что пропускает тесты, поэтому я обычно не слишком формализован заранее.

Answer 3

Предоставьте достаточно тестов, чтобы вы чувствовали себя комфортно - основываясь на ваших знаниях о реализации. Я не рассматриваю юнит-тестирование как полностью черный тест. Если вы знаете, что базовый класс никогда не вызывает какие-либо виртуальные методы (или, по крайней мере, ни один из них не переопределяется), обратите внимание на этот факт, но не дублируйте уже выполненные модульные тесты.

Юнит-тестирование, безусловно, можно довести до крайности - всегда стоит сбалансировать ценность, которую вы получаете от него, с затратами, которые вам обходятся.

Answer 4

При использовании TDD вы должны стремиться не к методам тестирования, а к поведению или возможностям вашего кода. Следовательно, при реализации подкласса вы можете ограничить тестирование только поведением, отличным от базового класса. Если сомневаетесь, напишите новый тест.