Рефакторинг в коде, содержащем тесты

#юнит_тесты #рефакторинг

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

Ответы

Ответ 1

Большинство юнит-тестов - это код, который пишется 1 раз и больше не изменяется.
В идеале, такие все вообще тесты. Код, который никогда не изменяется, рефакторить не нужно.

Более того, рефакторинг тестов зачастую еще и нежелателен - ведь тесты должны быть
независимыми, а выделение "общих частей" сделает их зависимыми друг от друга.

Наконец, юнит-тесты должны быть простыми, иначе придется писать тесты на тесты :)
А в простом коде рефакторинг, как правило, не нужен.

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

Еще один допустимый вид рефакторинга тестов - разбиение сложного теста на несколько
простых.


Ответ 2

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

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

Если тестируемый код написан нормально, если публичный интерфейс более-менее стабильный
(обратная совместимость не слишком часто ломается), то обычно тесты трогать не надо.

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

Сложную архитектуру разводить не стоит, тесты должны быть простыми. У тестов свои
стандарты качества: должно быть деление на arrabge-act-assert, не должно быть ветвлений
и т. п. И именно этих стандартов нужно придерживаться, а не приходить с трёхслойными
абстракциями из основного кода.