Перезапуск тестов

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

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

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

И что же означает это падение тестов? Обычно причины две:

1. Баги в продукте
2. Нестабильные тесты/Баги в тестах/Нестабильное тестовое окружение

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

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

Да, я понимаю, что у всех своя специфика, уникальный внутренний мир проекта, сроки горят, начальство негодует и KPI не выполняется. Все это может заставить вас игнорировать какие-то упавшие тесты. Как правило это просто пустые отмазки. Как правило, но далеко не всегда.  Но тем не менее не позволяйте нестабильным, хреново написанным тестам становиться нормой. Не делайте нормой нестабильное тестовое окружение. Это все инженерные задачи - они решаются (не всегда легко, но тем не менее решаются). Если, конечно, суть вашей работы не заключается в том, чтобы демонстрировать пару тысяч зеленых квадратиков on commit.