Бесконечный цикл запуска тестов. Практика "чертового колеса"

Зачастую, когда объем автотестов становится весьма большим, достаточно тяжело уделять внимание запускам тестов. Тесты выполняются долго, часть проблем выявляется только после серии прогонов тестов и т.д. Более того, весьма полезно, чтобы результаты приходили регулярно и изменения, внесенные в код подхватывались по мере их внесения. Да и по сути, запуск тестов - это очередная рутина, которую хорошо бы делать регулярно, но в итоге всё делается, как получится. Соответственно, надо бы это как-то автоматизировать. Тут как раз подходит практика "Чёртового колеса"

Что это такое? Да, по сути это запуск всех тестов в бесконечном цикле. Вот и всё. Но сама по себе идея, как и многие другие идеи, весьма проста в озвучивании. Реализация же требует некоторой возни. Вот сосредоточимся на этом.

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

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

Всё это очевидно и решаемо. Наиболее простой случай - это использование определенных опций командной строки для закрытия средства тестирования после завершения выполнения всех тестов. Как правило средства автотестирования подобную опцию предоставляют. В крайнем случае в командных процессорах операционной системы есть команда удаления процесса по определенному имени.

Теперь ключевой момент: как зациклить.

Самое простое, что приходит на ум - написать bat-файл (или sh-файл, если работаем с Unix системами), который содержит в себе инструкции по запуску тестов, а в конце осуществляется прыжок в начало файла. Для Windows данный bat-файл будет иметь следующий каркас:

{syntaxhighlighter brush: bash;fontsize: 100; first-line: 1; }:start echo Running infinitely goto start{/syntaxhighlighter}

Если создать такой файл и запустить, то он бесконечно будет выводить на экран "Running infinitely". Естественно, если внутри файла поместить инструкции по запуску конкретного приложения с конкретными параметрами, то эта строка будет выполняться циклически. Допустим, для того же SilkTest это будет выглядеть примерно так:

{syntaxhighlighter brush: bash;fontsize: 100; first-line: 1; }:start partner -q -r TestPlan.pln goto start{/syntaxhighlighter}

Вот как раз опция -q и закрывает приложение по завершению прогона тестов. По аналогии выбирается опция для других средств.

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

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

Какие преимущества нам дает данная практика:

  1. Функционал покрытый автотестами тестируется 24 часа в сутки 7 дней в неделю. Если исходить из предположения, что автотест работают столько же по времени, сколько тест проходится вручную, то уже сразу получаем выигрыш в 4,2 раза. То есть тот же объем тестов в те же сроки могут выполнить 4-5 человек.
  2. Результаты приходят достаточно оперативно, а изменения, внесенные в код, подхватываются на следующей итерации выполнения. Соответственно, мы достаточно быстро можем выявить систематические ошибки, соответственно, среагировать на них, внеся нужные изменения и буквально следующая итерация покажет, оказали ли изменения нужный эффект или нет
  3. Поскольку тесты выполняются непрерывно, использование "чертового колеса" позволит предоставить статистическую информацию по всем запускам в кратчайшие сроки. Ряд ошибок могут быть ложными и не воспроизводиться постоянно. Поэтому, нужно смотреть, как тот или иной тест выполнялся в течение последних нескольких запусков, так как может оказаться, что тест упал один раз и то по случайности.
  4. Нормальная работа "чертового колеса" требует стабильно работающих тестов. Соответственно, использование данной практики просто вынудит разработчиков тестов "укреплять" свои тесты различными recovery-сценариями.

Писать конечно свои вспомогательные инструменты конечно хорошо, но мы допустим используем сервер непрерывной интеграции. Он очень хорошо подходит под описание выше нужды. Там даже есть такая фича, как автоматически запускать билд на выполнение, как только произойдет добавление/изменения репозитория. Также, плюсы использования сервера непрерывной интеграции, что всю рутину, формирование репортаов, статистика, автоматический запуск, тригерры, уведомления, он берет на себя. Нам же остается только быстро выбрать настройки и все. Дело в шляпе. 

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

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