Home

Автор: Корина Пип (Corina Pip)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

• Тест-окружение ненадежно. Зачастую у тест-окружения недостаточно ресурсов железа, чтобы правильно работать под нагрузкой, которую генерируют автотесты. Или оно может быть неправильно настроено.
• Мы не используем ожидания (если речь о тестах Selenium). Сам тест неправильно написан и не учитывает асинхронные события, происходящие в интерфейсе в ходе тестирования. В некоторых случаях использование JavaScript снижает надежность наших тестов.

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

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

Помимо того, что баги не изучаются, у механизма повторных попыток есть еще одна досадная черта: один тест займет вдвое (или более) больше времени на прогон. Сначала мы его прогоняем, он падает, и мы прогоняем его еще как минимум один раз.

Итак, что же предпринять вместо повторных попыток?

• Если окружение медленное или ненадежное, лучшее решение – исправить окружение. Это помогает обойтись от обходных путей в тестах. Оно также сделает код чище – из него исчезнут все попытки, повторные попытки, и всякое такое.
• Если виноваты тесты, тесты надо изменить (и исправить). Мы должны создавать наилучшую, наиболее надежную версию теста, а не просто написать кусок кода и вычеркнуть тест из списка задач. Если окружение и тестируемое ПО не менялись, то каждый прогон теста должен возвращать одинаковые результаты. И он должен прогоняться за разумное время, а не за вдвое большее (хорошо, если вдвое – зависит от количества повторных попыток). Мы хотим быстрой обратной связи – то есть быстрых результатов тестирования.

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

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