Тестирование в стиле TSA

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

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

«Но что плохого в избыточном тестировании, Фил, разве ты не хочешь, чтобы твой код был безопасным? Если мы поймаем очередной баг до попадание в production, то разве оно того не стоит?» Да ни хрена оно того не стоит, и не зовите меня Фил. Из-за таких вот рассуждений мы и получили TSA и то как они сливают миллиарды на ощупывание яиц и конфискацию книпсеров.

Примечание переводчика: TSA — Transportation Security Administration — Управление транспортной безопасности США, которое люто ненавидят за феноменальную дотошность при досмотре (в частности в аэропортах).

Тесты не бесплатны

Каждая строчка кода, которую вы пишите, имеет цену. Нужно время, чтобы ее написать, нужно время, чтобы ее обновить, нужно время, чтобы прочитать и понять ее. Соответственно выгода от ее написания должна быть больше, чем ее стоимость. В случае с избыточным тестированием это определенно не так.

Подумайте об этом так: какова цена предотвращения бага? Если вам нужно написать 1000 строк теста, чтобы отловить случайное удаление Бобом строчки «validates_presence_of :name», то оно того стоит? Естественно нет (да, да, если вы работаете над системой контроля запуска ракет на Марс и ракета полетит в Белый Дом, если забыть указать ей имя, то можете это тестировать — но это ведь не ваш случай, так что забудьте).

Проблема выявления избыточного тестирования в том, что сложно придумать броский термин для этого. Нет ничего столь же компактного как test-first (тест первым), red-green (красный-зеленый) или других секси-терминов, которые помогают продвигать разработку через тестирование к ее заслуженному месту в центре сцены. Тестирование только того, что необходимо, требует тонкого подхода, опыта и немалой интуиции.

Семь «НЕ» тестирования

Все тонкости можно легко объяснить за 2 часа ужина с просвещенными собеседниками, однако в посте для этого не хватит места. Поэтому давайте подкинем дров в огонь дискуссии — я просто приведу список мнений без всяких тонкостей о том, как вам стоит тестировать ваше типичное Rails-приложение:

1. не стремитесь к 100% покрытию тестами;
2. соотношение кода к тестам выше 1:2 уже попахивает, выше 1:3 — воняет;
3. если тестирование отнимает больше 1/3 вашего времени, то скорее всего вы делаете это неправильно; вы определенно делаете это неправильно, если тестирование отнимает больше половины вашего времени;
4. не тестируйте стандартные ассоциации, валидации и скопы ActiveRecord;
5. приберегите интеграционные тесты для проблем, возникающих при объединении отдельных элементов (т.е. не используйте интеграционное тестирование для вещей, для которых можно использовать юнит-тесты);
6. не используйте Cucumber, если только вы не живете в волшебном королевстве не-программистов-писателей-тестов (или пришлите мне бутылочку волшебной пыли, если вы все-таки там!);
7. не заставляйте себя писать тест первым для каждого контроллера, модели или шаблона (мое обычное соотношение — 20% тест первым и 80% тест после).

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

Но вернемся к главному. Мы должны коллективно решить, что тестирование в стиле TSA (театральное качество покрытия тестами) полностью дискредитировало себя, прежде чем мы сможем двигаться дальше. Очень мало приложений являются настолько критически важными, что действительно требуют тестировать все.

Говоря мудрыми словами ^[1] Kent'а Beck'а, человека, который больше всех способствовал популяризации разработки через тестирование:

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

Автор: Svyatov