Мир завален благими намерениями и заброшенными тестовыми наборами. Не добавляйте к резне.
Вы когда-нибудь работали над проектом, в котором были модульные или интеграционные тесты, но вам говорили: «Да, не беспокойтесь о тестах - мы знаем, что некоторые из них терпят неудачу». В какой-то момент поддерживать тесты в актуальном состоянии с изменениями, внесенными в кодовую базу, стало слишком сложно, и те инвестиции, которые были вложены в написание тестов, теперь хорошо и верно отражены в столбце «списано».
Каковы основные предикторы этого сценария и как вы можете предотвратить это в своих проектах?
Тесты были незаметны
Не полагайтесь на разработчиков в проведении тестов. Иногда мы торопимся выпустить исправление или функцию или просто отвлекаемся на другие приоритеты. Конечно, разработчики, которые привыкли работать на основе тестирования, сначала спросят: Как мне запустить тесты? перед написанием кода, потому что им нужны ранние отзывы о правильности своей реализации. Но все же - нужно, чтобы тесты запускались автоматически. Вот почему вам необходимо регулярно использовать такие инструменты непрерывной интеграции, как Travis, Jenkins или CircleCI. Сделайте CI максимально простой и автоматической частью вашего рабочего процесса - вы должны получать его бесплатно для новых модулей и проектов. Подумайте о том, чтобы включить его в свой шаблон или скаффолдер для ваших новых модулей / проектов и попытаться автоматизировать любую начальную настройку, чтобы CI запускал тесты и любые шаги сборки или линтинг.
Тесты на самом деле были слишком хорошими
Вам может быть интересно, как это может быть проблемой. Но на самом деле очень важно, чтобы добавление нового теста для нового варианта использования или выявленного пограничного варианта было достаточно дешево. Точно так же поддержание существующего теста для обеспечения соответствия теста изменившимся требованиям должно быть достаточно простой задачей. Чтобы бороться с этим, ищите ширину, прежде чем углубляться. По моему опыту, разработчик, у которого есть набор хороших простых тестов, которые хорошо покрывают кодовую базу (но где тесты на самом деле можно поддерживать и использовать), находится в гораздо лучшем положении, чем разработчик, которому приходится слишком сильно бороться. поддерживать тесты в рабочем состоянии, потому что тесты настолько подробны и настолько точны, что есть много движущихся частей и проблем, о которых нужно думать. Я не говорю, что не нужно стремиться к высокой точности, реализму и даже полноте ... Я просто говорю, прежде всего, шире и учитывайте текущую стоимость любого написанного вами кода тестирования. Чего мы хотим избежать, так это сценария, при котором затраты на поддержание тестов в рабочем состоянии начинают превосходить нашу воспринимаемую ценность в их обновлении.
Тесты были слишком плохими
Заботьтесь о качестве вашего кода в ваших тестах так же, как вы делаете свой «настоящий» код. Не исключайте их из линтинга. Когда вы проводите обзор кода, убедитесь, что тесты удобны для сопровождения и читабельны, так же тщательно и время, как вы делаете это с остальной частью кодовой базы. Используйте инструмент покрытия кода, чтобы убедиться, что вы не оставляете слишком много зияющих дыр (это повышает ценность набора тестов, обеспечивая безопасный рефакторинг кода).
Просто тесты длились чертовски долго!
Не знаю, как вы, но я начинаю нервничать, если на выполнение набора тестов требуется более 60 секунд. Я обычно настраиваю тестовый костюм на запуск при каждом изменении кода, используя какой-то флаг --watch или наблюдатель файловой системы. Наборы тестов, запуск которых занимает десятки минут, определенно не будут использоваться разработчиком в процессе работы - они, вероятно, оставят их для CI. И чем позже откладываете обратную связь, тем она менее ценна. Если на выполнение тестов уйдет действительно много времени, у некоторых разработчиков возникнет соблазн даже не дожидаться завершения CI перед развертыванием. Тесты, выполнение которых занимает десятки минут, лучше удовлетворяют следующим условиям:
- они обязательно тестируют трудоемкий или высокоточный процесс или процедуру (например, тесты пользовательского интерфейса)
- они обеспечивают соразмерный уровень снижения рисков, который оправдывает их стоимость (как с точки зрения обслуживания, так и с точки зрения ожидания рабочего процесса).
Совет: иногда вы можете значительно ускорить тесты, просто применив некоторые разумные заглушки. Это само по себе компромисс, но о нем стоит подумать.
Надеюсь, эта статья оказалась для вас полезной и заставляла задуматься. Сообщите мне о своем опыте, реакции и мыслях в комментариях!
