Повторный запуск не исправляет тест

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

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

Что на самом деле меняет повторная попытка

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

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

Реестр, который следует хранить рядом с CI

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

Реестр также является полезной поверхностью для просмотра тестов, написанных агентами. Попросите агента составить сценарий, а затем попросите человека проверить его настройку, проверка и очистку. Политика повторных попыток - это настройка запуска, а не замена этой проверки. Публичная страница AnyTest описывает исследование с помощью URL-адресов и обзор пакета людьми; он не определяет, как следует выбирать ваш конкретный бюджет повторных попыток CI.

Ставим цифры на повторяющиеся работы

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

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

Правило выпуска, которое вы можете объяснить

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

Рассматриваемый вопрос прост: дала ли вторая попытка новые доказательства или просто цвет, который мы предпочли? Сохраняйте неудавшуюся попытку до тех пор, пока кто-нибудь не сможет ответить.