Unit Tests

Свершилось, я начинаяю писать цикл статей про unit tests. С января 2013 года я начал задумываться о создании курса по тестированию, разработке через тестирование, но времени катастрофически на это нет. При этом стали "проходить мимо" интересные моменты из реальной жизни, которые потом в будущем просто не собрать. В итоге месяца два назад я решил, что буду "по горячим следам" писать статьи, а затем как-то курс сам собой образуется.

Зачем же нужны тесты?

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

Дальше идет интересная закономерность, чем проще писать тест, тем лучше ваш код. Если вам тяжело протестировать ваш класс/метод, значит скорее всего в нем ощибка, допустим архитектурная. Простые примеры:

Да и потом в будущем вы что-то меняете, с тестами вы чувствуюте себя уверенее :), что ничего не сломали.

Так почему же большинство не пишет тесты?

Из адекватных объяснений у меня есть только два: не умеют и не могут, а скорее не хотят. На самом деле на своей шкуре знаю, как тяжело внедрить тестирование в большой проект, который годами развивался без тестов. На текущем моем проекте, как мне известно, до меня два раза пытались внедрить юнит тесты, затем я еще предпринимал попытки две или три.

Но внедрить тесты и начать их писать - дело не сложное. Думаю большинство так или иначе начинало это делать. Самое главное продолжить их поддерживать. Рано или поздно написание теста превращается в какое-то мучение, и большинство бросает это благородное занятие.

Причин возникновения таких ситуаций множество. Самая банальная и первая - генерация фикстур. Из теории, а возможно и из определения unit test (wiki), следует, что каждый тест должен быть полностью независим от других. Это означает, что перед каждым тестом вы должны заполнять базу данных своими индивидуальными фикстурами. А структура базы у долгосрочных проектов меняется, и все фикстуры падают. И так далее. При этом эта проблема возникает постоянно с ростом проекта. Сейчас, при написании статьи, я подумал, что на текущем моем проекте такая проблема снова есть и мучает всех. Буду думать...

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

Что же делать?

Вообще, код юнит тестов такой же код, он требует постоянного рефакторинга. Если вы не будете его улучшать, следить за ним, то его невозможно будет поддерживать. Чем понятнее и выразителен тест для другого программиста, тем лучше.

При написании кода мы стараемся дать сразу понять: что делает метод, что возвращает, что хранит переменная и т.д..

При написании теста мы стараемся показать сразу: что тестируем и какую ситуацию описывают входные данные и т.д..

В идеальном мире у вас чистые и понятные тесты с красивым и простым кодом проекта. Эти две составляющие подвергаются непрерывному рефакторингу и развитию.

О чем шла речь вначале?

Так вот в данном цикле статей, я не буду рассказывать о каких-то азах, которые можно прочитать в документации или на вики. В основном здесь будут публиковаться интересные на мой взгляд решения, правила, находки, best practice для меня на данный момент, которые я и мои коллеги применяем, а может хотим лишь применить :).

Комментарии