Пастки застарілих відповідей

Чи запускає Cypress тести паралельно і чи ретраїть упалі тести автоматично?

Обидва твердження хибні.

Паралельність: на одній машині Cypress виконує спеки послідовно — один процес, один браузер. Паралельно можна лише між кількома машинами: через Cypress Cloud (--record --parallel) або безкоштовно через матрицю CI і плагін на кшталт cypress-split.

Retries: за замовчуванням вимкнені. Їх треба явно ввімкнути в конфігу, зазвичай лише для CI.

// cypress.config.ts
export default defineConfig({
  retries: { runMode: 2, openMode: 0 },
});

Як зберегти логін і cookies між тестами?

Cypress.Cookies.preserveOnce прибрали з Cypress 12, а ручне копіювання cookies — крихкий обхідний шлях. Сучасна відповідь — cy.session: він кешує cookies, localStorage і sessionStorage після логіну й відновлює їх у наступних тестах, а validate перевіряє, що сесія ще дійсна.

Детальніше — у питанні про cy.session у розділі «Стан, сесії, ізоляція».

Як зробити паузу (sleep) у Cypress?

Технічно cy.wait(ms) справді робить паузу, але правильна відповідь на співбесіді — пояснити, чому так робити не варто: фіксована пауза робить тест і повільним, і нестабільним.

Замість неї: асерт, який сам ретраїться (should('be.visible')), або очікування конкретного запиту через cy.intercept і cy.wait('@alias'). Виправдане використання cy.wait(ms) рідкісне — наприклад, перевірка debounce, де час і є вимогою.

Як використовувати XPath у Cypress?

Нативної підтримки XPath немає, а офіційний плагін @cypress/xpath команда Cypress більше не підтримує. На старих проєктах його ще можна побачити, але радити його як рішення — ознака застарілих знань.

Задачі, для яких беруть XPath, закриваються вбудованими засобами: пошук за текстом — cy.contains, рух по дереву — .closest(), .parents(), .siblings(), .next(), семантичний пошук — Testing Library з cy.findByRole.

// XPath: //td[text()='Замовлення #1042']/parent::tr//button
cy.contains('td', 'Замовлення #1042').closest('tr').find('button').click();

Як правильно встановлювати Cypress?

Локально в проєкт, як dev-залежність: npm install --save-dev cypress. Тоді версія зафіксована в package.json і lock-файлі, у всіх розробників і в CI вона однакова, а запуск іде через npx cypress.

Глобальна установка дає різні версії на різних машинах і ламає відтворюваність. Окремо зберігається лише бінарник Cypress — у системному кеші, і його перевіряють через npx cypress verify.

Елемент прихований і клік не проходить. Що робити?

Спершу зрозуміти, чому він прихований. Якщо його перекриває модалка, лоадер чи cookie-банер — тест виявив реальну проблему або сам має спершу закрити перешкоду. Якщо елемент з'являється після дії — треба дочекатися стану через should.

{ force: true } вимикає перевірки actionability, і тест може пройти там, де користувач клікнути не зміг би. Виправдано лише для свідомих випадків на кшталт прихованого нативного чекбокса під кастомним, і з коментарем.

Чим requestTimeout відрізняється від responseTimeout?

requestTimeout (5 с) — скільки cy.wait('@alias') чекає, поки застосунок відправить запит. Якщо за 5 секунд запит не пішов — помилка «No request ever occurred».

responseTimeout (30 с) — скільки чекати відповідь: на перехоплений запит у cy.wait і на cy.request.

Тобто це два різні етапи: «чи пішов запит» і «чи прийшла відповідь». Діагностика різна: перший таймаут зазвичай означає, що дія в UI не спрацювала або intercept зареєстровано після неї, другий — повільний бекенд.

Як розпізнати застарілу відповідь про структуру Cypress?

Будь-який із лівих термінів у твоїй відповіді сигналізує, що досвід закінчився до версії 10.