Пять ошибок в работе с ожиданиями в UI‑автотестах, из‑за которых тесты падают через раз
Знакомый сюжет в любом проекте с UI‑автотестами. Один и тот же тест на CI ведёт себя по‑разному: вчера прошёл, сегодня упал, завтра снова прошёл. Локально работает всегда. В логах непонятное «Element not interactable», в скриншоте на момент падения элемент вроде на месте. Команда списывает на «flaky test», добавляет ретрай через JUnit Extension, через месяц добавляет ещё один уровень ретраев на CI. Пайплайн билда растёт с трёх минут до двадцати, потому что ретраи теперь срабатывают на половине прогонов. Доверие к автотестам падает, через полгода менеджмент возвращает ручное тестирование на критичные релизы.
Playwright: E2E‑тесты на JavaScript, которые не флакуют
Привет, Хабр!Flaky‑тесты — бич E2E‑автоматизации. Команда перезапускает пайплайн, пока не позеленеет. Доверие к тестам падает. В итоге CI‑статус игнорируется, и баг всё равно попадает в прод.Playwright — фреймворк от Microsoft для E2E‑тестирования — был построен с нуля, чтобы решить именно эту проблемную. В нем есть автоматические ожидания, изоляция через Browser Contexts и встроенный тест‑раннер. Разберем, чем он отличается от Selenium и Cypress, и как писать тесты, которые не падают от ветра.Почему тесты флакуют: корень проблемы
