Візуальне тестування в Cypress: процес

Cypress добре відтворює стан, який має потрапити на знімок. Тест може відкрити маршрут, підмінити нестабільну відповідь API, встановити розмір вікна та перевірити видиму ознаку готовності. Команда screenshot лише фіксує цей стан. Порівняння, зберігання еталонів і схвалення дає плагін, зовнішній сервіс або окремий процес перевірки.

У цьому посібнику ми проводимо одну перевірку сторінки з тарифами від локального запуску до CI. Головна увага на рішеннях, які прибирають хибні помилки: які дані зафіксувати, коли сторінка готова, де зберігати еталон і хто може схвалити зміну. Окремо розберемо, коли RenderLog краще доповнює Cypress для публічних сторінок, які переглядають не лише розробники.

Спершу визначте, за що відповідає Cypress

Залишайте перевірку в Cypress, коли тест має увійти до системи, створити записи, підмінити API або пройти сценарій перед знімком. Близькість до коду корисна: помилка може зупинити об'єднання змін, а розробник відтворить той самий стан локально. Спочатку опишіть його словами: маршрут, розмір вікна, користувач, мова, тема, тестові дані та елемент, який підтверджує завершення відтворення.

Встановлення плагіна для знімків ще не створює процесу перевірки. Вирішіть, чи лежатимуть еталони в Git, сховищі артефактів або кабінеті зовнішнього сервісу. Призначте людину, яка схвалює новий стан, і зберігайте слід цього рішення. Без власника команда поступово почне бездумно оновлювати знімки або ігнорувати помилки, хоч саме порівняння працюватиме правильно.

Використовуйте Cypress для станів із фікстурами, перехопленнями та діями користувача.
Називайте розмір вікна, мову, тему й стан користувача в описі перевірки.
Оберіть місце для еталонів і власника схвалення до першого запуску.
Винесіть стеження за публічною сторінкою окремо, якщо за нього відповідає інша команда.

Зробіть стан сторінки відтворюваним

Сторінка з тарифами може містити поточну дату, місцеву валюту, віддалені дані, вебшрифти, чат і змінний відгук. Фіксуйте лише змінні, які не стосуються мети перевірки. Підмініть відповідь із цінами, якщо тестуєте макет, задайте часовий пояс і мову, вимкніть анімацію через передбачене налаштування. Залишайте справжні дані, коли саме їхня зміна є ризиком.

Чекайте на видиму умову, а не на довільну затримку. Перевірте заголовок і потрібні картки тарифів, дочекайтеся відомої ознаки готовності застосунку. Cypress повторює багато команд до успіху, тому така перевірка надійніша за паузу приблизної тривалості. Відсутня картка має спершу дати зрозумілу функціональну помилку, а не лише великий і незрозумілий візуальний diff.

Підміняйте нестабільні дані лише тоді, коли їхнє значення не перевіряється.
Однаково задавайте вікно, часовий пояс, мову та колірну тему.
Використовуйте повторювані перевірки як ознаки готовності.
Ховайте найменшу можливу динамічну ділянку, яка не належить до перевірки.

Схвалюйте перевірений еталон, а не перший успішний файл

Запустіть тест і перегляньте весь знімок до того, як зробити його еталоном. Переконайтеся, що шрифти завантажились, банер згоди має очікуваний стан, дані присутні, а віджет підтримки не закрив кнопку. Перший успішний результат є лише кандидатом. Еталон набуває сенсу після того, як людина підтвердила бажаний стан продукту.

Коли дизайн змінюють навмисно, оновлюйте лише пов'язані знімки з перевірених результатів. Залишайте старий і новий варіанти видимими в запиті на зміни або в системі перегляду. Масова команда оновлення швидка, але разом із потрібним кольором може схвалити зниклий блок. Невеликі іменовані рішення зберігають зв'язок тесту з реальною зміною продукту.

Переглядайте кожного першого кандидата на еталон у повному розмірі.
Оновлюйте лише результати, яких торкнулася навмисна зміна.
Зберігайте еталон, поточний знімок і diff для невдалого запуску CI.
Фіксуйте рецензента або запит на зміни, де схвалили новий стан.

Налаштовуйте порівняння за доказами

Почніть із найсуворішого практичного порівняння в одному зафіксованому браузері та середовищі. Якщо краї літер відрізняються локально й у CI, спершу вирівняйте шрифти, версію браузера та образ системи. Якщо щоразу змінюється відео, замініть або вузько виключіть лише його ділянку. Великий загальний поріг може приховати зміщену кнопку в іншій частині сторінки.

Переглядайте diff разом з обома зображеннями. Сам відсоток змінених пікселів не пояснює, чи це безпечне згладжування шрифту, чи зникла кнопка покупки. Для блоку з особливими правилами робіть окремий знімок компонента. Повну сторінку знімайте, коли важлива її композиція. Поруч із порогом запишіть, яку саме природну різницю він має поглинати.

Зафіксуйте середовище до того, як вимірювати нормальне відхилення.
Подивіться, де виникає різниця, до підвищення допустимого порога.
Знімайте компонент окремо, якщо він потребує іншого правила.
Використовуйте відсоток як підказку для перегляду, а не остаточний висновок.

Зробіть помилку в CI зрозумілою без повторного запуску

Для кожної помилки завантажуйте еталон, поточний знімок, diff і журнали Cypress. Назва файлу має вказувати специфікацію, браузер і розмір вікна. Рецензент повинен відрізнити зміну продукту від сторінки, яка не завантажилась, не запускаючи роботу ще раз. Якщо бібліотека створює HTML-звіт, зберігайте його щонайменше протягом звичного циклу перевірки команди.

Класифікуйте результат до будь-якого оновлення. Завершення очікування є помилкою тесту або середовища. Стабільна сторінка без картки тарифу є зміною продукту. Перевірений новий дизайн є очікуваною зміною і може стати еталоном. Постійний шум навколо шрифтів вказує на розбіжність оточення. Такий розподіл зупиняє звичку схвалювати все лише заради зеленої збірки.

Зберігайте еталон, результат, diff, журнали та звіт тесту.
Додавайте браузер і розмір вікна до назви або метаданих.
Відокремлюйте незавершений запуск від виконаного порівняння.
Вимагайте перегляду перед схваленням очікуваної зміни.

Для спільного або регулярного перегляду використовуйте RenderLog

Перевірки в репозиторії природно підходять для станів, які мають блокувати код. Публічна сторінка з тарифами, сайт клієнта чи кампанія можуть мати іншу частоту й іншого власника. У RenderLog можна зберегти таку сторінку як перевірку, запускати за розкладом або через API та показувати еталон, поточний результат, diff й історію людям без доступу до CI Cypress.

Не дублюйте всі тести. Обирайте сторінки, де блокування випуску та постійне стеження справді є різними завданнями. Cypress може перевіряти підготовлений кошик до об'єднання коду, а RenderLog щоранку стежити за бойовою сторінкою тарифів. Прив'яжіть обидва процеси до рішень: розробник виправляє тестовий стан, а власник продукту переглядає зміну публічної сторінки.

Залишайте стани, що блокують об'єднання коду, у Cypress.
Виносьте регулярний перегляд публічних сторінок у спільну систему.
Не дублюйте стан без окремого власника й окремої дії.
Застосовуйте API RenderLog, коли запуском керує інша система.

Плагін Cypress, API знімків чи RenderLog?

Усі три підходи працюють зі знімками, але розв'язують різні завдання власності та перегляду. Обирайте за дією після зміни, а не лише за способом отримання зображення.

Рішення	Порівняння в Cypress	API знімків	RenderLog
Найкраще застосування	Стан із коду та перевірка перед об'єднанням	Застосунку потрібне лише зображення	Повторний перегляд сторінки різними командами
Керування станом	Фікстури, перехоплення, команди й перевірки	Параметри запиту та логіка клієнта	Збережені перевірки, сценарії, розклад і API
Перегляд еталона	Git, артефакти CI або сервіс плагіна	Створює сам клієнт	Еталон, результат, diff та історія разом
Типовий власник	Розробники й перевірка коду	Команда застосунку-клієнта	Розробка, продукт, операції, агенція або клієнт

Мінімальний процес візуального порівняння в Cypress

Приклади показують місце для керування станом, порівняння й доказів з CI. Пристосуйте команди плагіна до обраної бібліотеки, адже Cypress робить знімки, але сам не порівнює зображення.

cypress.config.ts

import { defineConfig } from "cypress";

export default defineConfig({
  viewportWidth: 1366,
  viewportHeight: 768,
  video: false,
  e2e: {
    baseUrl: "http://127.0.0.1:3000"
  }
});

cypress/e2e/pricing.cy.ts

describe("pricing page", () => {
  it("matches the approved desktop state", () => {
    cy.intercept("GET", "/api/prices", { fixture: "prices.json" }).as("prices");
    cy.visit("/pricing");
    cy.wait("@prices");
    cy.contains("h1", "Pricing").should("be.visible");
    cy.get("[data-testid=plan-grid]").compareSnapshot("pricing-desktop");
  });
});

CI artifact handoff

npx cypress run --browser chrome
# Upload cypress/screenshots/ and the visual plugin's diff output on failure.
# Keep scheduled public-page review in RenderLog when it has a non-code owner.

Першоджерела для цього посібника

Команди та налаштування Cypress змінюються. Для деталей API звіряйтеся з офіційною документацією, а цей посібник використовуйте для рішень про процес, відповідальність і перегляд.

Оберіть потрібний шар візуальної перевірки

Посібник із візуального регресійного тестування

Продумайте еталони, пороги й відповідальність до розширення покриття.

Візуальне тестування в Playwright

Порівняйте процес у репозиторії на основі Playwright.

Візуальне тестування в Selenium

Додайте візуальні докази до наявного набору Selenium.

API знімків вебсторінок

Створюйте разові або збережені запуски та отримуйте їхні результати.

Порівняння засобів візуального тестування

Зіставте продукти для компонентів, репозиторію та спільного перегляду.

Винесіть одну бойову сторінку за межі тестового набору

Залиште Cypress відповідальним за стани з коду, а одну публічну сторінку тарифів, реєстрації чи кампанії збережіть у RenderLog для регулярного перегляду та зрозумілої історії еталонів.

Створити робочий простір RenderLog

Візуальне тестування в Cypress без нестабільних знімків