Cypress — инструмент автоматизации web-приложений, который объединяет выполнение тестов, assertions и удобную диагностику в браузере. Его часто выбирают команды frontend, которым важно быстро видеть состояние интерфейса во время разработки и проверять сценарии вместе с изменением приложения.
Для качественного набора нужно понимать модель исполнения Cypress. Команды добавляются в очередь, а результат асинхронного действия не появляется в обычной переменной сразу после строки cy.get. Попытка писать Cypress как синхронный браузерный скрипт создаёт неожиданные ошибки даже в простых сценариях.
Очередь команд и повторяемые запросы
Queries и assertions могут повторяться до выполнения ожидания или истечения таймаута. Действия имеют другую семантику: Cypress ожидает возможность взаимодействия, но не повторяет произвольно бизнес-операцию после каждого неуспеха. Автоматическое ожидание не означает, что любая строка безопасна для повторного выполнения.
Используйте цепочку Cypress и callbacks там, где нужен результат. Не добавляйте действие с побочным эффектом внутрь callback проверки, который может вызываться несколько раз. Например, повторная отправка формы из should способна создать дублирующиеся заказы и превратить тест в источник дефекта.
Минимальный локальный стенд
Создайте пустую учебную папку и сохраните index.html с формой ниже. Запустите в ней python -m http.server 8080. Этот сервер обслуживает только учебную страницу; реальные аккаунты и внешний API отсутствуют. Для практики требуется Python и установленный в отдельном Node-проекте Cypress.
<label>Имя <input data-cy="name"></label>
<button data-cy="save">Сохранить</button>
<p data-cy="status" role="status"></p>
<script>
document.querySelector('[data-cy=save]').onclick = () => {
const name = document.querySelector('[data-cy=name]').value.trim();
setTimeout(() => {
document.querySelector('[data-cy=status]').textContent =
name ? 'Сохранено' : 'Введите имя';
}, 100);
};
</script>После npm install --save-dev cypress откройте npx cypress open, выберите E2E и разрешите создать конфигурацию. Добавьте cypress/e2e/profile.cy.js с примером. Затем выполните npx cypress run --spec cypress/e2e/profile.cy.js. Версию Node выбирайте по требованиям установленного Cypress и фиксируйте зависимости lock-файлом.
describe('Учебная форма профиля', () => {
it('показывает ошибку для пустого имени', () => {
cy.visit('http://127.0.0.1:8080');
cy.get('[data-cy=name]').clear();
cy.get('[data-cy=save]').click();
cy.get('[data-cy=status]').should('have.text', 'Введите имя');
});
});Ожидается один успешный сценарий. Задержка в странице демонстрирует ожидание состояния без cy.wait с фиксированным числом. Упражнение проверяет клиентское сообщение; оно не подтверждает запись профиля в backend или правильность реальной серверной валидации.
Что проверять в настоящем приложении
В собственном тестовом кабинете создайте пользователя с известным именем. Отправьте пробельное значение и ожидайте ошибку без сохранения. Затем в отдельном тесте сохраните допустимое имя и проверьте новое значение после повторного чтения.
Наблюдайте не только UI, но и запрос, если он входит в цель. Несовпадение пользовательского текста и backend-результата является важным дефектом. Данные и правила упражнения заранее согласуют: пустое имя не обязательно запрещено в каждом продукте.
Контроль сети через intercept
cy.intercept позволяет наблюдать запросы и управлять ответами для определённых сценариев. Это удобно для проверки ошибки сервера, долгой загрузки и пустого списка. Перехват регистрируют до действия, иначе быстрый запрос может пройти раньше настройки наблюдения.
Разделяйте тесты с настоящим backend и тесты с подставленным ответом. Вторые показывают, как интерфейс обрабатывает заданный контракт, но не доказывают его реализацию сервером. Если все ответы заглушены, нужна отдельная проверка совместимости клиента и API.
Наблюдение запроса и подмена ответа должны быть различимы в коде. В первом случае интерфейс обращается к настоящему сервису, а тест ждёт конкретный alias и изучает результат. Во втором случае тест сам задаёт status и body. Стабильность подставленного ответа полезна для воспроизведения редкой ошибки, но не подтверждает её вероятность в production. Отдельно проверяйте, как UI очищает loading, показывает понятную причину и позволяет повторить действие после восстановления сервиса. Одного появления уведомления бывает недостаточно: форма может навсегда остаться disabled, хотя сообщение корректно. Такой сценарий проверяют повторным действием и наблюдением нового результата.
Состояние и повторное использование сессии
Каждый тест должен запускаться самостоятельно и не зависеть от успешного входа в предыдущем. Возможности управления сессией полезны для ускорения подготовки, но требуют проверки валидности сохранённого состояния и понятных ключей для разных пользователей.
Не проверяйте весь продукт под одним общим аккаунтом. Параллельные сценарии изменят настройки и заказы друг друга. Подготовка через API или fixture должна создавать изолированные данные, а проверка UI начинаться с контролируемого состояния.
Ограничения проверяют на своём сценарии
Cypress ориентирован на web. Нативные экраны Android и iOS требуют других средств. Сценарии нескольких вкладок, разных origins и внешней аутентификации нужно сверять с текущей документацией и прототипировать до выбора инструмента: поддержка и необходимые механизмы зависят от сценария и версии.
Не отключайте проверки безопасности браузера как универсальное лечение. Такое изменение способно скрыть проблему реального пользовательского окружения. Если продукт зависит от сложного внешнего потока, выделите контроль своей части и согласованный интеграционный тест.
Как расследовать падение
Сначала проверьте, на какой команде изменилось состояние. Посмотрите снимок DOM, фактический URL и нужный сетевой ответ. Если assertion не дождался текста, выясните, отправлен ли запрос и обновился ли элемент. Увеличение timeout без причины лишь удлиняет расследование.
Сохраняйте артефакты CI и версию сборки. Успех повторного прогона не доказывает отсутствия проблемы: исходное падение остаётся фактом для анализа. Отдельно учитывайте повторные попытки и ошибки подготовки, чтобы отчёт не создавал ложное впечатление устойчивости.
Типичные ошибки и выводы
Хрупкий Cypress-набор часто использует CSS-классы оформления, фиксированные паузы и порядок тестов как часть подготовки. Ещё одна ошибка — рассчитывать, что retry-ability исправит асинхронность бизнес-процесса без явного ожидаемого состояния.
Сильный набор использует понятные локаторы, независимые данные и assertions результата. Cypress удобен, когда команда понимает его очередь команд и честно различает клиентскую проверку, реальную интеграцию и ограниченный учебный пример.
После исправления локатора повторите тест отдельно и в полном наборе: успешная изолированная проверка может скрывать зависимость от предыдущего сценария.