Автоматизация и инженерия тестов

E2e-тест прогоняет всю систему так, как это делал бы реальный пользователь — через UI и все слои (фронт, бэкенд, база), чтобы проверить, что цельный пользовательский поток работает. Он даёт наивысшую уверенность в работе продукта в целом, но это самый медленный, хрупкий и дорогой вид теста, поэтому в пирамиде их держат мало.

Assert — это проверка внутри теста, которая роняет его, когда ожидаемое условие не выполняется. Виды: assertTrue/assertFalse, assertEquals/assertNotEquals, assertNull, assertThrows, плюс различие soft и hard (soft-asserts собирают сбои и продолжают, hard-asserts останавливаются сразу). Инструменты: JUnit/TestNG, AssertJ, Hamcrest, pytest, Chai.

Flaky-тест то проходит, то падает недетерминированно на одном и том же коде. Частые причины: гонки по времени, неявные ожидания, зависимость от порядка тестов, общее или грязное состояние и нестабильность сети. Чинят заменой sleep на явные ожидания, изоляцией состояния, снятием связи по порядку — затем тест карантинят и либо стабилизируют, либо удаляют, ведь flaky-тест подрывает доверие ко всему набору.

Page Object Model — это паттерн для UI-автоматизации: каждая страница или экран — это класс, выставляющий свои элементы и действия как методы, так что тесты вызывают методы страницы, а не сырые локаторы. Он сосредотачивает поддержку локаторов в одном месте, убирает дублирование и держит тесты читаемыми. Применяется в наборах Selenium, Appium и Playwright.

Appium даёт одну кодовую базу, управляющую и iOS, и Android, так что тесты пишутся один раз — но он медленнее и более flaky и может отставать в поддержке новых функций ОС. Нативные инструменты (Espresso для Android, XCUITest для iOS) быстрее и стабильнее и живут в коде приложения, так что их могут писать разработчики, но требуют двух кодовых баз и примерно вдвое больше поддержки.

CI (Continuous Integration) автоматически собирает и тестирует каждое изменение по мере его попадания, рано ловя проблемы интеграции. CD (Continuous Delivery/Deployment) автоматизирует доставку проверенных сборок к проду или в него. Вместе они решают integration hell и ошибки ручных релизов, давая быструю обратную связь и повторяемый, проверяемый путь от коммита до работающего ПО.

Хороший автотест независим и атомарен, детерминирован (не flaky) и читаем. У него понятные setup/teardown (фикстуры, предусловия, постусловия), он даёт понятное сообщение об ошибке и в идеале проверяет одну логическую вещь. Это ложится на принципы FIRST — Fast, Independent, Repeatable, Self-validating, Timely — делая набор надёжным и дешёвым в поддержке.

Web-локаторы: id, name, class, tag, CSS-селектор, XPath и текст ссылки. id самый быстрый и стабильный; XPath самый гибкий, но хрупкий и медленный, поэтому CSS обычно предпочтительнее. На мобайле добавляются accessibility id и resource-id (Android). Компромисс всегда — стабильность против гибкости: выбирайте самый стабильный селектор, который позволяет разметка.

Мокирование заменяет реальную зависимость — сервис, базу, часы или сетевой вызов — управляемой подменой, возвращающей заранее заданные ответы. Оно держит тест изолированным, быстрым и детерминированным, позволяет имитировать трудновоспроизводимые условия (ошибки, таймауты, закрытый ночью магазин) и убирает зависимость от внешнего состояния, которое вы не контролируете во время прогона.

Линтер — это статический анализатор, который читает исходный код без запуска и помечает нарушения стиля и вероятные ошибки — неиспользуемые переменные, неопределённые имена, подозрительные паттерны, расхождения форматирования. Он держит единый стиль кода и ловит класс багов рано, до того как код вообще выполнится, часто как часть CI-пайплайна.

Нагрузочное тестирование измеряет, как система ведёт себя под ожидаемой и пиковой нагрузкой — проверяет пропускную способность, время отклика и ёмкость и находит узкие места до того, как на них наткнутся пользователи. Инструменты: JMeter, k6, Gatling, Locust. Родственные подвиды — стресс (за пиком), спайк, soak/выносливость (длительный) и тестирование масштабируемости.

Unit-тест проверяет наименьшую изолированную часть кода — отдельную функцию или модуль — независимо от остальной системы, обычно с замоканными зависимостями. Он ценен тем, что быстро выполняется, точно указывает место дефекта, минимизирует регрессию, ловя поломки рано, и даёт разработчикам быструю обратную связь при изменении кода.

Антипаттерн — это распространённое, но контрпродуктивное решение, которое выглядит полезным, но создаёт проблемы. В автоматизации тестов: жёстко заданные ожидания (Thread.sleep), взаимозависимые тесты, требующие порядка, скопированный код тестов, оставленные в наборе flaky-тесты и пирамида-рожок (слишком много медленных UI-тестов, слишком мало unit-тестов).

Ветка (branch) — это независимая линия разработки. Базовые команды: git clone копирует репозиторий, git pull получает обновления, git commit фиксирует изменения, git push загружает их. Git Flow — это модель ветвления с долгоживущими main и develop плюс короткоживущими feature/*, release/* и hotfix/*, дающая структурированный путь от работы к релизу.

Hook перед каждым тестом (в JUnit @Before / @BeforeEach) выполняется перед каждым тест-методом, давая каждому тесту свежее изолированное состояние — для дешёвых изменяемых фикстур. Hook на класс (@BeforeClass / @BeforeAll) выполняется один раз перед всеми тестами класса и должен быть static, используется для дорогой общей подготовки вроде открытия соединения с БД. Правило: перед каждым — ради изоляции, на класс — для дорогих ресурсов, которые можно безопасно делить только на чтение.

Мутационное тестирование вносит маленькие намеренные дефекты (мутанты) в код — меняет оператор, меняет константу — затем перезапускает набор тестов. Если тест падает, мутант убит; если все тесты проходят, мутант выжил, обнажая пробел. Оно измеряет качество самих тестов (правда ли они ловят баги), идя дальше покрытия строк, которое лишь показывает, что код выполнился.

Ускоряют запуском тестов конкурентно, отсечением избыточных, мокированием медленных зависимостей и переносом проверок на более низкие (быстрые) уровни. Параллельный прогон запускает один набор конкурентно, часто на нескольких устройствах или браузерах; распределённый шардирует набор по узлам, так что разные тесты идут на разных машинах, сокращая общее время по часам.

Нагрузочное тестирование проверяет поведение под ожидаемой реалистичной нагрузкой, подтверждая, что система достигает целей (время отклика, пропускная способность) при обычном и пиковом трафике. Стресс-тестирование выходит за эти пределы, чтобы найти точку отказа и увидеть, как система падает и восстанавливается. Синтетический мониторинг гоняет скриптованные транзакции по расписанию против прода, наблюдая доступность и производительность во времени. Нагрузка проверяет ёмкость, стресс ищет пределы, синтетика наблюдает постоянно — это не предрелизный гейт.

Используйте бинарный поиск (git bisect): раз за разом тестируйте сборку в середине подозрительного диапазона, оставляя только ту половину, где сохраняется переход от рабочей к сломанной. Это O(log n) проверок против O(n) при тесте каждой версии подряд. Сузьте дальше, сперва выяснив, баг в коде или в данных — это может исключить целый класс сборок до бисекта.

Никогда не завязывайтесь на неконтролируемое реальное состояние. Лучше: замокать часы или флаг открыто/закрыто, чтобы предусловие всегда выполнялось детерминированно. Иначе засеять базу в известное открытое состояние или вызвать API в setup теста для подготовки данных. Общее правило: тест должен владеть своими предусловиями — контролируйте время и внешнее состояние через моки, seeding или setup, а не живое окружение.

Это не баг, если отказ — корректная обработка реального условия — нет сети, файл слишком большой или неподдерживаемого типа, сервер недоступен, истёкшая сессия — и пользователю ясно сказано почему и он может повторить. Это баг, если отказ при валидных условиях, без причины, без повтора или сообщение неверное либо вводит в заблуждение. Проверка — ожидаемое против фактического плюс корректная деградация.

Сначала соберите данные: откройте DevTools для разбора запроса/ответа, включите прокси, прочитайте логи приложения и отладьте бэкенд, если есть доступ. Затем рассуждайте по всей цепочке: дубликат номера заявки, кириллический символ от генератора, серверная валидация, отклоняющая номер или текст, упавшая БД, отказ сети, медленный/истёкший ответ или некорректный запрос от фронта.

Вероятные причины: устаревший edge-кэш CDN (один узел держит старую версию), гео- или локале-зависимое согласование контента (заголовки Accept-Language или гео выбирают версию), устаревший локальный кэш браузера или VPN, меняющий выходной узел. Расследуйте, разбирая заголовки запроса/ответа в DevTools или прокси и сравнивая ETag, Last-Modified и Cache-Control между устройствами.