Эта статья является переводом статьи из блога Uber. Обычно мы в Qameta Software не занимаемся переводами, но мимо этой статьи пройти не смогли. Хороший и исчерпывающий материал о том, что такое flaky-тесты, какие они бывают и как с ними справляться (с некоторыми проявлениями). Часть материала, посвященную переезду Uber с микросервисов на монорепо я опустил, оставив только то, что напрямую связано с отработкой flaky-тестов.
Юнит-тесты лежат в основе любой Continuous Integration (CI) системы. Они позволяют обеспечить контроль над качеством кода при высоких темпах разработки, предупреждая инженеров о багах в новом коде и регрессии в кодовой базе. Кроме того, они снижают стоимость разработки за счет обнаружения ошибок на ранних этапах. Именно поэтому построение стабильной и работающей тестовой инфраструктуры является одним из базовых требований для любой крупной разработки.
К сожалению, flaky-тесты осложняют жизнь тем, кто это требование пытается выполнить. Давайте считать, что мы будем принимать тест как flaky если на любых двух воспроизведениях он возвращает разные результаты: прошел или упал, — без изменения кода. Такие тесты чаще всего возникают в результате одной из двух причин: недетерминированность на уровне кода (порядок исполнения тредов и другие сложности с многопоточностью) или неоднородностью окружений, в которых выполняется тестирование (на одной машине все работает хорошо, а на CI-сервере тесты падают).
Давайте рассмотрим простой пример, на котором будет понятно, откуда у проблемы ноги растут:
