Про "моргающие" тесты: GTAC 2016 — How Flaky Tests in Continuous Integration (Gmail)

«Моргающие» тесты — неизбежность (1.5% от запусков)
Интересная дока из доклада https://pdfs.semanticscholar.org/02da/46889ee3c6bc44bfa0fc45071195781b99ce.pdf

На каждое изменение запускается 3.5М тестов. Все результаты в базу и там уже хранятся данные за 2 года.

Не позднее, чем через 2 (хотя иногда 3) часа разработчик узнает о том как прошли тесты по его изменению

Каждый фейл анализируется с предыдущим по целому ряду параметров (все берется из базы результатов), чтобы понять действительно ли это «моргание» в том же самом месте или что то новое.

В течении 6 месяцев один из докладчиков анализировал 2-летние результаты прогонов тестов, а также полную историю изменений исходников, которые этими тестами проверялись.

Результаты анализов планируется использовать для быстрого определения «моргающего» теста, в т.ч. без его перезапуска

Наблюдения:

• Чем чаще тест переключается из «зеленого» в «красный», тем с большей уверенностью мы можем считать его «моргающим» (разработчик не может так часто ломать код)
• Если у тестов совпадает история, то скорее всего причина не в «моргании», а в поломанном коде.

Анализ по корреляции изменений в исходниках:

Корреляция «поломок» по авторству изменений исходников (чем выше процент, тем меньше шансов, что тест отвалился из-за «моргания»)

Чем больше людей меняет файл, тем меньше шансов на то, что fail был из-за «моргания».

В конце 15 минут интересных вопросов-ответов.

PS если кому то интересно, то они ищут еще желающих проанализировать их данные.
PS2 остальные доклады на сайте конфы и в плейлисте.
PS3 рекомендую эти «Using Test Run Automation Statistics to Predict Which Tests to Run» и «Need for Speed — Accelerate Automation Tests From 3 Hours to 3 Minutes«