Home

Автор: Дейв Вестервельд (Dave Westerveld)

Оригинал статьи: https://offbeattesting.com/2017/08/17/getting-fast-and-consistent-automation/

Перевод: Ольга Алифанова

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

Начнем со скорости. Что мы можем сделать, чтобы автоматизация ускоряла вам работу?

Принцип скорости 1 – избегайте падений

Падения тестов замедляют вам работу. Они требуют дебага и понимания, почему тест упал. Конечно же, тесты должны падать, если они натолкнулись на баг, но ваш труд замедлит вообще любое падение тестов.

Что же делать, если у вас на руках чересчур часто падающий набор тестов?

Первый шаг – это определить, как собрать данные о падениях. Какие данные вы можете получить из системы запуска тестов? Можно ли выкопать что-то в git-логах, сообщающее вам, как часто вам нужно менять определенные тесты? Как только данные у вас на руках, легко определить, какие тесты создают проблемы, и отправить их на рефакторинг. К тому же, когда способ легко получать информацию найден, вы будете контролировать процесс и в дальнейшем. Всегда стремитесь к тому, чтобы ваши тесты приносили пользу.

Принцип скорости 2 – пусть тесты падают как можно раньше

Если тест должен упасть, то чем раньше он это сделает после вноса изменений, тем лучше. Это применимо вне зависимости от того, вызвано ли падение теста найденным багом. Если тест упал из-за свежевнедренного бага, то чем раньше мы об этом узнаем, тем проще исправить проблему. Если падение вызвано тем, что тест нуждается в обновлении – то чем раньше мы узнаем об этом, тем проще провести дебаг и определить, почему тест падает и что в нем стоит поменять.

Как же это улучшить? Чтобы тесты падали раньше, их нужно запускать как можно раньше. Выясните, почему они не запускаются сразу же после изменений. Возможно, это сделано сознательно: вы постепенно даете доступ к коду все более широкой аудитории и запускаете все больше тестов  на каждом этапе. В этом случае у вас должны также быть тесты, падения которых все менее и менее вероятны от стадии к стадии.

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

Принцип скорости 3 – избавляйтесь от занудных тестов

Тесты, которые тяжело запускать или понять, никак не помогут вам ускорить процесс. Если для запуска тестов требуются сложные настройки, и только три человека в команде знают, как это делается, то неужели вы полагаете, что это повысит скорость вашей работы? Конечно же, нет! Нам нужны тесты, которые легко сможет запустить любой член команды. Удобство использования и доступность вашего тестового фреймворка – это очень важно.

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

Принцип надежности 1 – поощряйте хорошие практики программирования

Интеграционные тесты могут таить в себе опасность. Они могут поощрять стабильное срабатывание тестов за счет отсутствия хороших практик разработки. Я поясню: представьте, что у вас два компонента, общающихся друг с другом через API. Если все ваши тесты на уровне интеграции убеждаются только в том, что эти компоненты работают вместе, вы можете начать поощрять кривое и косое программирование интерфейса между этими компонентами. Скажем, если появляется баг, который нужно быстро исправить, разработчики могут воткнуть костыль на прямой вызов класса одним компонентом у другого вместо того, чтобы менять API. Если ваши тесты помогают определять интерфейсы между этими компонентами, людям сложнее "обмануть" систему, создавая код, так как сами тесты определяют качество интерфейсов.

Это всего лишь один пример того, как хорошие тесты могут влиять на хорошие практики программирования.

Принцип надежности 2 – сохраняйте чистоту ваших тестов

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

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

Принцип надежности 3 – тесты должны быть краткими

Проблема с длинными тестами в том, что когда они падают, вы тратите много времени на разбирательства, что именно пошло не так. Если прогон занимает 15 минут, то дебаг займет как минимум 15 минут – возможно, больше. Как часто вам приходится запустить тест всего один раз, чтобы понять, что с ним не так? Может, это не кажется слишком уж важным, но чем больше у вас долгих тестов, тем больше времени вы потратите на поиск проблем. Это ведет к расхождениям между планируемым и реальным временем релиза – сначала все будет идти гладко, а потом вам внезапно понадобится несколько часов на дебаг "долгих" тестов.

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

Обсудить в форуме