Тестовый класс может стать “Объектом бога”?
Перефразируя от Брайана Баттона:
-
Они обычно используются в качестве глобального примера, почему это так плохо? Потому что вы скрываете зависимости вашего приложения в своем коде, вместо того, чтобы показывать их через интерфейсы. Создание чего-то глобального, чтобы избежать его распространения, - это запах кода .
-
Они нарушают принцип единой ответственности : в силу того факта, что они контролируют свое собственное творение и жизненный цикл.
-
Они по своей сути заставляют код быть тесно . Это во многих случаях затрудняет их тестирование.
-
Они переносят состояние в течение всего срока службы приложения. Еще один удар по тестированию, так как вы можете столкнуться с ситуацией, когда нужно заказывать тесты, что является большим нет-нет для юнит-тестов. Зачем? Потому что каждый модульный тест должен быть независимым от другого.
5 ответов
450 тестов в одном классе звучит много, но насколько это плохо, зависит от того, как они организованы. Если все они действительно независимы друг от друга и членов тестового класса, это может не иметь большого значения - кроме как найти конкретный тест, должно быть сложно.
С другой стороны, если тестовый класс имеет членов которые используются только некоторыми тестами и игнорируются другими, это тестовый запах, называемый Obscure Test , содержащий такие корневые причины, как General Fixture и Irrelevant Information ( обратите внимание на жаргон - я вернусь к этому).
Есть несколько способов организации тестов в классы. Наиболее распространенными шаблонами являются Testcase Class per Class , Testcase Class per Feature и Testcase Class per Fixture .
То, как вы структурируете тесты, важно не только во время написания тестов, но и впоследствии по причинам ремонтопригодности. Уже по одной этой причине я бы сказал, что рефакторинг ваших тестов будет стоящим усилием. В TDD база тестового кода (почти) так же важна, как и реальная база кода, и к ней следует относиться с таким же уважением.
На эту тему есть целая книга под названием Шаблоны тестов xUnit: рефакторинг Тестовый код , который я не могу рекомендовать. Он содержит полный язык шаблонов, который имеет дело с модульным тестированием и TDD, и все имена шаблонов, которые я здесь использовал, происходят от него.
Я склонен говорить, что рефакторинг ваших тестов стоил бы усилий. В TDD база тестового кода (почти) так же важна, как и реальная база кода, и к ней следует относиться с таким же уважением.На эту тему есть целая книга под названием Шаблоны тестов xUnit: рефакторинг Тестовый код , который я не могу рекомендовать. Он содержит полный язык шаблонов, который имеет дело с модульным тестированием и TDD, и все имена шаблонов, которые я здесь использовал, происходят от него.
Я склонен говорить, что рефакторинг ваших тестов стоил бы усилий. В TDD база тестового кода (почти) так же важна, как и реальная база кода, и к ней следует относиться с таким же уважением.На эту тему есть целая книга под названием Шаблоны тестов xUnit: рефакторинг Тестовый код , который я не могу рекомендовать. Он содержит полный язык шаблонов, который имеет дело с модульным тестированием и TDD, и все имена шаблонов, которые я здесь использовал, происходят от него.
Вместо того, чтобы считать число, я бы подумал, эффективны ли они. То есть, сколько тестов сломается при модификации одной строки? Если вы тратите время на исправление дюжины неудачных тестов, значит, проблема; тесты не должны повторять одни и те же вещи снова и снова, и если это так, то они нуждаются в рефакторинге.
Я бы, вероятно, не стал проводить рефакторинг тестовой базы сверху вниз, скорее позволяя ему течь органично от тест-записи-рефакторинга разработки через тестирование. Напишите тест, внедрите улучшения и, если> 1 теста завершится неудачно, проведите рефакторинг тестов
Набор модульных тестов Framework будет иметь большое количество совпадений в функциях запуска и настройки. В этом случае изменение нескольких методов может легко сломать каждый тест. Особенно и ORM.
При этом тесты следует группировать по функциональности. Запрос типа X, объединения, объединения, извлечение DDL / схемы, кэширование выборки, создание операторов и т. Д.
Разделите тестовые классы, чтобы каждый класс концентрировался на определении одного типа поведения. В качестве примера я написал учебник по TDD , где есть примерно один тестовый класс для одного типа поведения (в игре тетрис: падающие блоки, вращающиеся части и т. Д.).
Рефакторинг тестов одинаково важно для рефакторинга кода, потому что тесты должны быть полезны как документация, документирующая намерение того, что система должна делать. Тесты являются спецификацией системы.
Как Тодд Гарднер упомянул в своем ответе , если многие тесты терпят неудачу из-за изменения одного метода, то многие из тестов проверяют одно и то же поведение и строки того, что каждый тестовый тест размыт. Это приводит к тому, что когда тесты терпят неудачу, трудно понять, что именно было сломано, потому что многие, казалось бы, несвязанные тесты терпят неудачу одновременно. Кроме того, когда необходимо изменить поведение системы, вам также необходимо обновить тесты. Но если обязанности тестов не ясны, будет сложно понять, как следует изменить тест или когда тест устарел и должен быть удален. Возможно, вам даже придется изменить множество тестов, даже если изменение поведения было небольшим.
450 тестов в одном классе - это очень много. Что проверяют тесты, как их зовут? Основаны ли они на поведении системы (это хорошо) или между ними и реализацией существует соотношение 1: 1? Если они тестируют много не связанных между собой вещей, было бы хорошо разделить обязанности между несколькими тестовыми классами.
Поведение нужно изменить, также нужно обновить тесты. Но если обязанности тестов не ясны, будет сложно понять, как следует изменить тест или когда тест устарел и должен быть удален. Возможно, вам даже придется изменить множество тестов, даже если изменение поведения было небольшим.450 тестов в одном классе - это очень много. Что проверяют тесты, как их зовут? Основаны ли они на поведении системы (это хорошо) или между ними и реализацией существует соотношение 1: 1? Если они тестируют много не связанных между собой вещей, было бы хорошо разделить обязанности между несколькими тестовыми классами.
Поведение нужно изменить, также нужно обновить тесты. Но если обязанности тестов не ясны, будет сложно понять, как следует изменить тест или когда тест устарел и должен быть удален. Возможно, вам даже придется изменить множество тестов, даже если изменение поведения было небольшим.450 тестов в одном классе - это очень много. Что проверяют тесты, как их зовут? Основаны ли они на поведении системы (это хорошо) или между ними и реализацией существует соотношение 1: 1? Если они тестируют много не связанных между собой вещей, было бы хорошо разделить обязанности между несколькими тестовыми классами.
будет трудно понять, как следует изменить тест или когда тест устарел и должен быть удален. Возможно, вам даже придется изменить множество тестов, даже если изменение поведения было небольшим.450 тестов в одном классе - это очень много. Что проверяют тесты, как их зовут? Основаны ли они на поведении системы (это хорошо) или между ними и реализацией существует соотношение 1: 1? Если они тестируют много не связанных между собой вещей, было бы хорошо разделить обязанности между несколькими тестовыми классами.
будет трудно понять, как следует изменить тест или когда тест устарел и должен быть удален. Возможно, вам даже придется изменить множество тестов, даже если изменение поведения было небольшим.450 тестов в одном классе - это очень много. Что проверяют тесты, как их зовут? Основаны ли они на поведении системы (это хорошо) или между ними и реализацией существует соотношение 1: 1? Если они тестируют много не связанных между собой вещей, было бы хорошо разделить обязанности между несколькими тестовыми классами.
1 связь между ними и реализацией? Если они тестируют много не связанных между собой вещей, было бы хорошо разделить обязанности между несколькими тестовыми классами. 1 связь между ними и реализацией? Если они тестируют много не связанных между собой вещей, было бы хорошо разделить обязанности между несколькими тестовыми классами.Да, но тестовый класс, являющийся «божественным объектом», не кажется мне проблемой.