Когда разработчики впервые открывают для себя прелести разработки через тестирование — это как переход в новый, лучший мир, где гораздо меньше стресса и незащищенности. Этот прекрасный опыт действительно стоит отпраздновать. Но осознание преимуществ тестирования — только первый шаг к просветлению. Самое сложное — понять что НЕ нужно тестировать.
Если новичку можно и не заботиться о том что не стоит тестировать в первый день, то на второй день ему бы лучше начать вникать в это. Люди — создания привычки, поэтому если вы начнете формировать плохую привычку избыточного тестирования с самого начала, то вам будет гораздо труднее избавиться от нее потом. А избавиться от этой привычки вы должны.
«Но что плохого в избыточном тестировании, Фил, разве ты не хочешь, чтобы твой код был безопасным? Если мы поймаем очередной баг до попадания в production, то разве оно того не стоит?» Да ни хрена оно того не стоит, и не зовите меня Фил. Из-за таких вот рассуждений мы и получили TSA и то как они сливают миллиарды на ощупывание яиц и конфискацию книпсеров.
Примечание переводчика: TSA — Transportation Security Administration — Управление транспортной безопасности США, которое люто ненавидят за феноменальную дотошность при досмотре (в частности в аэропортах).
Тесты не бесплатны
Каждая строчка кода, которую вы пишите, имеет цену. Нужно время, чтобы ее написать, нужно время, чтобы ее обновить, нужно время, чтобы прочитать и понять ее. Соответственно выгода от ее написания должна быть больше, чем ее стоимость. В случае с избыточным тестированием это определенно не так.
Подумайте об этом так: какова цена предотвращения бага? Если вам нужно написать 1000 строк теста, чтобы отловить случайное удаление Бобом строчки «validates_presence_of :name», то оно того стоит? Естественно нет (да, да, если вы работаете над системой контроля запуска ракет на Марс и ракета полетит в Белый Дом, если забыть указать ей имя, то можете это тестировать — но это ведь не ваш случай, так что забудьте).
Проблема выявления избыточного тестирования в том, что сложно придумать броский термин для этого. Нет ничего столь же компактного как test-first (тест первым), red-green (красный-зеленый) или других секси-терминов, которые помогают продвигать разработку через тестирование к ее заслуженному месту в центре сцены. Тестирование только того, что необходимо, требует тонкого подхода, опыта и немалой интуиции.
Семь «НЕ» тестирования
Все тонкости можно легко объяснить за 2 часа ужина с просвещенными собеседниками, однако в посте для этого не хватит места. Поэтому давайте подкинем дров в огонь дискуссии — я просто приведу список мнений без всяких тонкостей о том, как вам стоит тестировать ваше типичное Rails-приложение:
- не стремитесь к 100% покрытию тестами;
- соотношение кода к тестам выше 1:2 уже попахивает, выше 1:3 — воняет;
- если тестирование отнимает больше 1/3 вашего времени, то скорее всего вы делаете это неправильно; вы определенно делаете это неправильно, если тестирование отнимает больше половины вашего времени;
- не тестируйте стандартные ассоциации, валидации и скопы ActiveRecord;
- приберегите интеграционные тесты для проблем, возникающих при объединении отдельных элементов (т.е. не используйте интеграционное тестирование для вещей, для которых можно использовать юнит-тесты);
- не используйте Cucumber, если только вы не живете в волшебном королевстве не-программистов-писателей-тестов (или пришлите мне бутылочку волшебной пыли, если вы все-таки там!);
- не заставляйте себя писать тест первым для каждого контроллера, модели или шаблона (мое обычное соотношение — 20% тестов первыми и 80% тестов после).
Учитывая все те сотни книг о том, как начать применять разработку через тестирование, мне бы хотелось, чтобы была одна или две книги о том, как потом приручить этого зверя. Существует большое количество тонкостей в определении что стоит тестировать, а что нет, но все они теряются, когда все фокусируются на одних и тех же примерах как тестировать.
Но вернемся к главному. Мы должны коллективно решить, что тестирование в стиле TSA (театральное качество покрытия тестами) полностью дискредитировало себя, прежде чем мы сможем двигаться дальше. Очень мало приложений являются настолько критически важными, что действительно требуют тестировать все.
Говоря мудрыми словами Kent'а Beck'а, человека, который больше всех способствовал популяризации разработки через тестирование:
Мне платят за код, который работает, а не за тесты, поэтому моя философия заключается в том, чтобы тестировать настолько мало, насколько это возможно для достижения нужного уровня уверенности (подозреваю, что мой уровень уверенности выше, чем стандарты индустрии, но возможно это просто мое эго). Если я обычно не допускаю ошибок определенного типа (как передача неверных аргументов в конструктор, например), то я не тестирую это.
