Почему не пишут юнит-тесты

Сейчас почти нет никого, кто не слышал про юнит-тесты. Многие знают, что TDD (test driven development) - это круто, потому что тесты позволяют:

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

Тем не менее тесты пишут не все. А если и пишут, то редко запускают. Бывает, что и часто запускают, но небольшое покрытие кода.

Анализ ситуации на примере нескольких проектов, показал, что есть несколько причин такого попустительства:

• лень;
• незнание;
• недоверие;
• бесполезность существующих тестов;
• тесты тяжело поддерживать;
  
• тесты долго выполняются.
  

Лень. Она же отсутствие свободного времени. Можно по-разному бороться с этим явлением. Например, одному талантливому, но жутко занятому программисту X повесили рядом с рабочим местом плакат: "X, когда уже напишешь юнит-тесты!". Удивительно, но через некоторое время это повысило покрытие кода с 0 до 20%. Но, как правило, лень скрывает другие, более глубокие причины.


Незнание. Казалось бы, самый простой способ - отправить человека на тренинг, где ему быстро все популярно объяснят. Увы, у многих программистов слово "тренинг" вызывает аллергию. Действительно, ведь проще никуда не ходить и читать хабрахабр, нонейм и т.д. Однако чтение статей и книг по юнит-тестам может дать эффект, а может и не дать. По опыту, лучше всего TDD обучать на "живых" примерах в рабочей атмосфере. Пару дней (недель или часов, от инерции мышления) - и человек начинает мыслить иначе. Другой вариант - собрать короткую-совещание и провести презентацию (а то и не одну) разных аспектов TDD. Кстати, этот пост написан материалам именно такой встречи.


Недоверие. Признаюсь, N лет назад, когда впервые услышал об автоматическом тестировании, я не поверил, что оно работает. И даже те, кто несколько лет пишут автотесты, не всегда верят в такую практику как Test First (вначале тесты, потом код). Другие искренне считают, что их код и так идеальный, и юнит-тесты - лишняя трата времени. Приходится убеждать и напоминать, что "Совершенный код" - всего лишь название книги.


Бесполезность существующих тестов. Одна из самых опасных вещей. Может быть вызвана тем, что вместо юнит-тестов пишут интеграционные тесты, которые трудно и нудно поддерживать, потому что они вызывают целую кучу непонятно как связанных классов. Напоминаю, что настоящие юнит-тест должен тестировать только один юнит - класс или модуль. Также может быть вызвана "замусоренной" архитектурой - когда невозможно эмулировать вызов зависимых классов и поэтому написать полноценные тесты.
Но главная причинв бесполезности тестов - что их запускают непозволительно редко. И вручную. Тесты должны всегда запускаться автоматически. А если падают - вся команда должна получать оповещения.

Тесты тяжело поддерживать. Как правило, это связано с тем, что не придерживаются практики Test First, которая заключается и в том, что после появления ошибки вначале её нужно воспроизвести в тестах, а потом чинить. Либо опять же много интеграционных тестов. Может быть вызвано и тем, что не используются вспомогательные тестовые фреймворки (для .Net самые распространённые Rhino Mocks и Moq).


Долго выполняются. А значит - редко запускаются. И в итоге запускаются не всеми. Что ведет к тому, что тесты становятся бесполезными. Долго - это больше минуты. Здесь обычно все просто. Юнит-тесты не должны обращаться к базе, файлам или другим сетевым ресурсам. Однако интеграцию тоже нужно тестировать. Хороший вариант известен давно: разнести автотесты на группы - интеграционные и юнит-тесты. Юнит-тесты запускать при коммите или при каждой автоматической сборке. Интеграционные - при ночном билде.


Ну и в завершение - список анти-паттернов юнит-тестирования.
Читать дальше...