ci
5 статей
-
Flaky-тесты: почему автотесты мигают и как это лечить
Тест то зелёный, то красный — без изменений в коде. Разбираем 6 главных причин flaky-тестов, конкретные фиксы по каждой и как ловить нестабильность в CI. С чек-листом.
-
Автотесты, которые не в CI, — это хобби: как встроить тесты в пайплайн и не утонуть
400 автотестов, которые гоняются «иногда, локально» — это не автоматизация. Разбор от первого лица: слои прогонов (PR-гейт с бюджетом в минуты / после merge / ночью), шардирование и почему параллель валит зависимые тесты, retry-политика без маскировки флаки (passed-on-retry = жёлтый, не зелёный), карантин с двумя выходами, правило красного main, артефакты падений (trace вместо повторного дебага) и метрики здоровья suite.
-
Что автоматизировать, а что оставить руками — и почему «автоматизируем всё» убивает suite
«Автоматизируем всё» через полгода превращается в красный suite, которому никто не верит. Разбор от первого лица: тест, который чинили полгода, а надо было удалить; почему автотест стоит не «написать», а «содержать годами»; что стоит автоматизировать (стабильное, частое, дорогое руками, детерминированное) и что оставить человеку; пирамида как калькулятор решений; почему флаки-тест хуже отсутствующего и чек-лист «автоматизировать или нет».
-
Тестовые данные в автотестах: источник флака и связности — и как их готовить
Тестовые данные — один из самых незаметных источников flaky-тестов, сильнее локаторов. Изоляция, детерминизм (freeze clock, seeded Faker), уникальность в параллели, фабрики vs фикстуры vs API-setup, очистка и анонимизация прод-данных. Чек-лист на 12 пунктов.
-
Testcontainers: реальные БД, Kafka и Redis в тестах вместо моков и общего стенда
Как тестировать интеграцию против настоящего Postgres, Kafka и Redis в Docker — без вранья моков и флакающего общего стенда. Wait strategies, reusable containers, Ryuk, модули, CI и чек-лист внедрения на 10 пунктов.