Интересно! А давайте разбираться - возможно вы не уловили идею статьи.
Рераны мы используем в пункте 1 - где главная цель сделать пайплайны зелеными. Это важно в контексте релизов - у нас их может быть несколько раз за день, и поэтому красные пайплайны могут поломать наши планы.
И если бы на этом статья заканчивалась - то я бы с вами согласилась. Но там есть следующие шаги.
Например - пункт 2 - находить тесты, которые падают. Именно для этого мы настроили ночные прогоны, и именно поэтому в них не используем рераны.
Так же есть дежурства - пункт 5 - где мы эти падения разбираем и фиксим, а не просто собираем в беклоге. И как уже написала - причины бывают разные. И это не всегда баг приложения.
Да, такое у нас бывает — это отдельная классика флаки: тест падает в прогоне, а локально не воспроизводится, потому что причина не в сценарии, а в пересечении по общим данным/состоянию при параллельном запуске.
Что делаем:
стараемся разводить тестовые данные по уникальным ID через fake() из библиотеки d42 - т.е. каждый тест создаёт свои объекты
с гарантированно уникальными идентификаторами, где нельзя полностью изолировать - вводим cleanup перед созданием данных, чтобы не было конфликтов с предыдущими прогонами
Но все равно периодичски натыкаемся на такие ситуации - например в старых тестах, где изначально не добавляли чистки данных.
С тезисом «лечить болезнь, а не симптомы» согласна.
Но важное уточнение: не каждый флаки = баг в продукте. Они еще бывают из‑за:
хрупкости самого теста: могли сами тест корявенько написать или данные для него не так подготовить
нестабильности тестовой среды/CI: ресурсы, сеть и пр
внешних зависимостей/моков
Поэтому я за то, чтобы флаки разбирать и классифицировать по источнику, а не просто «бороться с тестами» или «всегда считать это багом». Цель одна: меньше шума, больше доверия к сигналу, быстрее находить реальные дефекты.
Все занимает не так много времени как кажется. И при текущем графике удается совмещать и работу, и отдых, и активности.
Если подробнее посмотреть по календарю:
Мы ведем дайджест ежемесячно. В каждой команде есть ответственный, который собирает полезности, которые могут быть полезны другим. В помощь идут закрытые тикеты в Jira и память коллег. Потом формируем общий список - и дайджест готов. Смотрим, радуемся, берем новшества себе на заметку.
Раз в месяц смотрим доклад. Выделяем на это один час в рабочее время. Дополнительная подготовка - только выбрать что смотреть. Проголосовать в чатике не так уж и долго. При этом нет обязательного для всех посещения - понимаем, что может наложиться другая встреча, которую нельзя пропустить.
На митап собираемся по запросу. Сейчас это где-то раз в 2-3 месяца. Может и реже. Проводится также в рабочее время, по продолжительности - 1 или 1,5 часа (если нужно что-то обсудить в разрезе команд). Чтобы не было перегруза - можем в этот месяц не смотреть доклад и не ставить другие активности. К митапам требуется подготовка спикеров - здесь уже тратится часть личного нерабочего времени.
Воркшопы - также по запросу, раз в несколько месяцев. Подготовка к нему у кураторов - в нерабочее время, зато потом при повторе - уже все готово и заново делать ничего не нужно. На прохождение воркшопа может уйти рабочий день. Мы заранее предупреждаем команды, следим, чтобы в этот день не было важных релизов. Можно подключиться, взять задание и выделить на него столько времени, сколько получится. То, что не успеваешь доделать в отведенное время - можно доделать позже, но уже в нерабочее время. Развитие - оно такое. Требует времени. Зато потом быстрее решаются задачи.
Как-то так пробуем сохранить баланс между развитием, работой и отдыхом.
Интересно! А давайте разбираться - возможно вы не уловили идею статьи.
Рераны мы используем в пункте 1 - где главная цель сделать пайплайны зелеными. Это важно в контексте релизов - у нас их может быть несколько раз за день, и поэтому красные пайплайны могут поломать наши планы.
И если бы на этом статья заканчивалась - то я бы с вами согласилась. Но там есть следующие шаги.
Например - пункт 2 - находить тесты, которые падают. Именно для этого мы настроили ночные прогоны, и именно поэтому в них не используем рераны.
Так же есть дежурства - пункт 5 - где мы эти падения разбираем и фиксим, а не просто собираем в беклоге. И как уже написала - причины бывают разные. И это не всегда баг приложения.
Стало ли понятнее?)
Спасибо за спасибо ! 😊
Да, такое у нас бывает — это отдельная классика флаки: тест падает в прогоне, а локально не воспроизводится, потому что причина не в сценарии, а в пересечении по общим данным/состоянию при параллельном запуске.
Что делаем:
стараемся разводить тестовые данные по уникальным ID через
fake()из библиотеки d42 - т.е. каждый тест создаёт свои объектыс гарантированно уникальными идентификаторами, где нельзя полностью изолировать - вводим cleanup перед созданием данных, чтобы не было конфликтов с предыдущими прогонами
Но все равно периодичски натыкаемся на такие ситуации - например в старых тестах, где изначально не добавляли чистки данных.
С тезисом «лечить болезнь, а не симптомы» согласна.
Но важное уточнение: не каждый флаки = баг в продукте. Они еще бывают из‑за:
хрупкости самого теста: могли сами тест корявенько написать или данные для него не так подготовить
нестабильности тестовой среды/CI: ресурсы, сеть и пр
внешних зависимостей/моков
Поэтому я за то, чтобы флаки разбирать и классифицировать по источнику, а не просто «бороться с тестами» или «всегда считать это багом». Цель одна: меньше шума, больше доверия к сигналу, быстрее находить реальные дефекты.
Все занимает не так много времени как кажется. И при текущем графике удается совмещать и работу, и отдых, и активности.
Если подробнее посмотреть по календарю:
Мы ведем дайджест ежемесячно. В каждой команде есть ответственный, который собирает полезности, которые могут быть полезны другим. В помощь идут закрытые тикеты в Jira и память коллег. Потом формируем общий список - и дайджест готов. Смотрим, радуемся, берем новшества себе на заметку.
Раз в месяц смотрим доклад. Выделяем на это один час в рабочее время. Дополнительная подготовка - только выбрать что смотреть. Проголосовать в чатике не так уж и долго. При этом нет обязательного для всех посещения - понимаем, что может наложиться другая встреча, которую нельзя пропустить.
На митап собираемся по запросу. Сейчас это где-то раз в 2-3 месяца. Может и реже. Проводится также в рабочее время, по продолжительности - 1 или 1,5 часа (если нужно что-то обсудить в разрезе команд). Чтобы не было перегруза - можем в этот месяц не смотреть доклад и не ставить другие активности. К митапам требуется подготовка спикеров - здесь уже тратится часть личного нерабочего времени.
Воркшопы - также по запросу, раз в несколько месяцев. Подготовка к нему у кураторов - в нерабочее время, зато потом при повторе - уже все готово и заново делать ничего не нужно. На прохождение воркшопа может уйти рабочий день. Мы заранее предупреждаем команды, следим, чтобы в этот день не было важных релизов. Можно подключиться, взять задание и выделить на него столько времени, сколько получится. То, что не успеваешь доделать в отведенное время - можно доделать позже, но уже в нерабочее время. Развитие - оно такое. Требует времени. Зато потом быстрее решаются задачи.
Как-то так пробуем сохранить баланс между развитием, работой и отдыхом.