Comments 6
Достойное уважения количество тестов и их запусков в день, имею опыт с количеством тестов примерно на порядок меньше, но проблемы моргающих тестов тоже есть. Не только от вас слышал историю про то, что упавший тест тупо перезапускается ещё раз, и вроде и понимаю что когда инфраструктура большая и тестов много лучшего варианта нет, но всё равно, отключение моргающих тестов не очень нравится. А вы учитываете изменение в характере теста, типа того что был стабилен 100 билдов, и тут херак, начал моргать, является ли это алярмом и говорит ли, что им стоит срочно заниматься?
Насчет отключения тестов действительно, может звучать опасно, но здесь стоит определить, насколько тест должен быть нестабильным, чтобы было очевидно, что вреда он приносит больше, чем пользы. Иначе каждый работающий с тестом человек в компании будет разбираться с уже известной проблемой.
Что касается 100 стабильных билдов и затем внезапные падения - тоже хороший вопрос. Для этого у нас есть отдельный маленький сервис, который работает в билдах для мерджа в RC (там ожидается, что ветки проверены и багов уже быть не должно). Если тест с хорошей статистикой внезапно сломался и упал во всех сборках несколько раз подряд, ответственные сразу получают нотификацию.
Хотел несколько моментов уточнить, а вы не хотели уйти в сторону когда тестов на API больше чем тестов UI? Так как UI тесты да еще и в таком количестве часто могут быть не стабильными из за того же драйвера через который запускаются и если не секрет какой процент погрешности упавших тестов вы допускаете, что бы билд ушел в продакшен?
Отличный вопрос! Дело в том, что наши UI-тесты очень далеки от Е2Е тестов, они атомарны и очень быстры, для каждого теста все подготовки данных делаются через API-запросы, а средняя длина сценария после логина и загрузки страницы составляет 1-3 секунды. Кроме того, мы стараемся по минимуму работать с полноценным веб-приложением, большинство тестов работают с облегченными демо-страницами или плейбуками.
Для того, чтобы билд с упавшими тестами ушел в продакшен, каждый упавший тест должен быть проверен ответственными, но в нашем случае это суммарно несколько десятков тестов в день перед каждым деплоем, что не такая большая проблема.
здравствуйте, можете ли вы дать статьи и материалы на темы: как сделать Е2Е тесты атомарными и быстрыми, как реализовывать облегченные демо-страницы или плейбуки. Хотел бы тоже реализовать подобное решение. Заранее благодарю
Я поискал по нашим статьям и, пожалуй, специальных материалов на эти темы у нас нет, но касаемо этих вопросов ответы такие:
- Делаем E2E тестов атомарными и быстрыми. В этом случае тесты, разумеется, уже не будут E2E, правильнее теперь их называть UI-тестами. Атомарность могут обеспечить всего 2 вещи: дизайн тест кейсов и ускоренная подготовка данных. Например, вместо E2E сценария, где пользователь обычным образом регистрируется, логинится и начинает работать с веб-приложением, тест кейс должен предполагать минимальное число действий, чтобы получить нужный результат. Для этого кроме сокращения числа необязательных и длительных степов, мы еще и по максимуму стараемся перенести их на сторону API. Стандартных инструментов здесь, как правило, недостаточно, поэтому на бэкенде бывает нужно написать дополнительные тестове эндпоинты, которые помогут создать ускоренную регистрацию, логин, и подготовку аккаунта. Это самые затратные шаги. Идеально, если после логина сразу же произойдет редирект в нужную вью с подготовленным для теста состоянием. Тогда оставшаяся UI часть теста представляет из себя пару кликов и проверку, в нашем случае эта часть длится 2-3 секунды для подавляющего числа тестов.
- Про демо-страницы так подробно рассказать не смогу, т.к. я сам не фронтендер, но мы используем архитектуру микро-фронтендов, которая уже стала де-факто стандартом в индустрии, по этому запросу гуглится огромное количество статей. Далее на демо-странице должно быть замокано все взаимодействие с внешней частью страницы, дополнительно могут быть добавлены переключатели состояния элементов страницы, т.к. в реальности они определяются именно внешними элементами. Очень удобно, когда эти параметры являются параметрами URL, тогда можно просто по ссылке получить нужное состояние страницы.
Надеюсь, ответил :) Если у вас остались более специфичные вопросы - милости прошу в ЛС
Как избавиться от нестабильных тестов