Может ли тестовый класс стать «объектом Бога»?

Question

Я работаю над бэкэндом для Python ORM с открытым исходным кодом. Библиотека включает в себя набор из 450 тестовых наборов для каждого бэкэнда, которые объединены в один гигантский тестовый класс.

Для меня это звучит как много для одного класса, но я никогда не работал над проектом, в котором имеет 450 тестовых случаев (я считаю, что в этой библиотеке ~ 2000 тестовых случаев, не включая тестовые случаи для каждого бэкэнда). Правильно ли я чувствую, что это немного высокого уровня (учитывая, что на самом деле нет магического числа, над которым вы должны что-то разбить), или это просто не так уж сложно для тестового класса иметь столько тестов?

И даже если это не слишком много тестовых случаев, как можно было бы провести рефакторинг слишком большого тестового класса? Большая часть моих знаний о рефакторинге заключается в том, чтобы убедиться в наличии тестов для кода, который подвергается рефакторингу. Мне никогда не приходилось сталкиваться с ситуацией, когда сами тесты нуждаются в рефакторинге.

EDIT : Раньше я говорил, что это юнит-тесты, что не совсем так. Это более подходящее название интеграционных тестов.

Answer 1

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

С другой стороны, если в тестовом классе есть члены, которые используются только некоторыми из тестов и игнорируются другими, это тестовый запах под названием Obscure Test , содержащий такие корневые причины, как General Крепеж и Неактуальная информация (обратите внимание на жаргон - я вернусь к этому).

Существует несколько способов организации тестов в классах. Наиболее распространенные шаблоны: Класс тестового набора для класса , Класс тестового набора для объекта и Класс тестового набора для прибора .

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

Существует целая книга по этому предмету под названием xUnit Test Patterns: Refactoring Test Code , которую я не могу рекомендовать достаточно. Он содержит полный язык шаблонов, который касается модульного тестирования и TDD, и все названия шаблонов, которые я здесь использовал, происходят от него.

Answer 2

Набор модульных тестов Framework будет иметь много общего в функциях запуска и настройки. Изменение нескольких методов может легко сломать каждый тест в этом случае. Особенно и ОРМ.

Тем не менее, тесты должны быть сгруппированы по функциональности. Запрос типа X, объединения, объединения, извлечение DDL / схемы, кэширование выборки, создание операторов и т. Д. *

Answer 3

Разделите тестовые классы так, чтобы каждый класс концентрировался на указании одного вида поведения. В качестве примера я написал учебник TDD , в котором есть примерно один тестовый класс для одного типа поведения (в игре тетрис: падающие блоки, вращающиеся фигуры и т. Д.).

Рефакторинг тестов одинаково важен для рефакторинга кода, потому что тесты должны обеспечивать хорошую ценность в качестве документации, документирующей намерение системы. Тесты являются спецификацией системы.

Как Тодд Гарднер упомянул в своем ответе , если множество тестов не удается из-за изменения одного метода, то многие из тестов тестируют то же поведение и линии того, что каждый тест тестирует, размыты. Это приводит к тому, что когда тесты не пройдены, трудно понять, что именно было сломано, потому что многие, казалось бы, не связанные тесты терпят неудачу одновременно. Кроме того, когда необходимо изменить поведение системы, вам также необходимо обновить тесты. Но если обязанности тестов не ясны, будет трудно понять, как тест должен быть изменен или когда тест устарел и должен быть удален. Возможно, вам даже потребуется изменить множество тестов, даже если изменение в поведении было небольшим.

450 тестов в одном классе звучит как очень. Что тестируют тесты, как их зовут? Сосредоточены ли они на поведении системы (что хорошо), или существует соотношение 1: 1 между ними и реализацией? Если они тестируют много несвязанных вещей, то было бы хорошо разделить обязанности на множество тестовых классов.

Answer 4

Вместо того, чтобы считать число, я бы подумал, эффективны ли они. То есть, при выполнении однострочной модификации сколько тестов ломается? Если вы тратите время на исправление дюжины тестов, то есть проблема; тесты не должны проходить одни и те же вещи снова и снова, и если они есть, они нуждаются в рефакторинге.

Я, вероятно, не стал бы реорганизовывать тестовую базу сверху вниз, а просто позволил бы ей органично вытекать из тест-рефактора тестовой разработки. Напишите тест, внедрите усовершенствование, и если> 1 тест не пройден, проведите рефакторинг тестов

Answer 5

Да, но тестовый класс, который является "объектом бога", не кажется мне проблемой.