Англійська мова для Cypress і Playwright Testing

Розмови про тестування від початку до кінця, як правило, обертаються навколо однієї повторюваної проблеми: тріщини. Незалежно від того, використовуєте ви Cypress або Playwright, словник для опису причин, чому тести провалюються періодично — умова перегонів, автоматичне очікування, затримка мережі — це те, що насправді допомагає команді виправити основну причину, замість того, щоб просто додавати ще одну спробу і сподіватися.

Ключовий словник

Спостереження з кінця до кінця (E2E-тестування) Тест, який вправляє програму так, як це зробив би справжній користувач, перевіряючи справжній переглядач за допомогою повного потоку, а не тестуючи окремий модуль або функцію. Приклад: «Ця помилка не була б виявлена лише за допомогою наших тестів — вона з’являється тільки тоді, коли повний поток замовлення виконується з кінця до кінця проти реального браузера.»

Селектор Рядок або стратегія, яку використовують для знаходження певного елемента на сторінці, наприклад, селектор CSS, текстовий вміст або спеціальний тестовий атрибут, наприклад, data-testid.

• Приклад: « Цей селектор відповідає класу CSS, який використовується виключно для стилізації, отже він порушується кожного разу, коли дизайнер змінює цей клас — нам слід переключитися на спеціальний тестовий атрибут замість цього. » *

** Авто-чекати ** Вбудована поведінка Cypress і Playwright, яка автоматично повторює спробу виконання твердження або дії протягом певного часу, перш ніж ця спроба зазнає невдачі, замість очікування вручну. Приклад: « Нам не потрібне явне очікування — автоматичне очікування вже повторює це твердження доки не з’ явиться елемент або не буде досягнуто тайм- аута. »

Ліскоподібний тест (лускоподібність) Тест, який неодноразово проходить і зазнає невдачі у ідентичних запусках без будь- яких змін у коді, зазвичай, через проблеми з часом, необроблену асинхронну поведінку або взаємозалежність тестів.

• Приклад: « Цей тест не працює під навантаженням CI, що зазвичай вказує на умову гонки, яка просто не відтворюється надійно на швидкій локальній машині. » *

• Зачекай Заздалегідь визначені, повторно використовувані тестові дані — наприклад, файл JSON, що представляє відповідь API — використовуються для встановлення послідовних, передбачуваних умов для тесту, а не для покладання на реальні або випадкові дані.

• Приклад: “Ми завантажуємо цей інструмент замість того, щоб вдарити по реальному API, тому вхідні дані тесту залишаються послідовними, незалежно від того, коли або де він запускається.” *

** Перехоплення мережі ** Практика перехоплення мережевих запитів під час тестування і повернення контрольованої, заздалегідь визначеної відповіді, замість того, щоб дозволити запиту потрапити до реального сервера. Приклад: «Ми тут замінили відповідь API платежу, тому цей тест не залежить від доступності реального платіжного шлюзу і не ризикує здійсненням фактичного платежу.»

** Утверждение ** Вираз у тесті, який перевіряє, чи є очікувана умова істинною, наприклад, елемент видимий або містить певний текст, що призведе до невдачі тесту, якщо умова не буде виконано.

• Приклад: « Ця заява перевіряє, чи існує елемент, але не те, чи він насправді видимий — прихований елемент все одно може пройти цю перевірку неправильно. » *

** Тест ізольованості ** Принцип, за яким кожен тест має виконуватися незалежно, не залежно від стану, залишеного попереднім тестом, так що тести можна виконувати у будь- якій послідовності або паралельно з надійністю.

• Приклад: « Цей тест пройде тільки якщо він буде запущений після іншого специфічного тесту, що означає, що нам бракує ізоляції тесту — кожен тест повинен встановити свій власний стан з нуля. »*

Звичайні фрази

** В обзорах коду: **

• Цей селектор пов’язаний з класом CSS, який використовується для стилізації — чи можемо ми додати спеціальний data-testid, щоб тест не розбивається, коли змінюється дизайн?
• «Ми додаємо тут твердо кодовану чергу замість того, щоб покладатися на автоматичну чергу — що зазвичай маскує справжню проблему часу, а не виправляє її»
• «Цей тест залежить від даних, залишених попереднім тестом, який порушує ізоляцію тесту і зазнає невдачі, якщо ми коли-небудь запустимо тести в іншому порядку»

В стоячих позах:

• «Вчора я замінив ланцюг крихких CSS-селекторів атрибутами data-testid; сьогодні я підтверджую, що виправив тріщини, які ми бачили в CI»
• «Я заблокований на тесті, який провалюється лише в CI — я підозрюю, що існує умова перегонів між викликом API і оновленням інтерфейсу, яке не враховується»
• «Я закінчив додавання мережевого застою для тестування потоку платежу, тому він більше не залежить від реального платіжного шлюзового доступу»

** В обговореннях тестової стратегії: **

• «Ми повинні покладатися на автоматичне очікування і правильні твердження замість довільних викликів сну, оскільки сплячі або марнують час, або не достатньо довго під навантаженням»
• «Фіксатори роблять наші тести відтворюваними незалежно від того, що насправді є в базі даних стажування в той час, коли вони працюють»
• «Ізоляція тестів варте вартості установки — тріщини, залежні від порядку тести розмивають довіру до всього набору набагато швидше, ніж трохи повільніше, але надійне.»

Фрази, яких слід уникати

**Скажите “тест сломан” для теста на ломкий. ** Замість цього скажіть: «цей тест є нерівним — він провалюється періодично без зміни коду, що зазвичай вказує на умову гонки або проблему з часом» — пошкоджений тест провалюється постійно, в той час як нерівний тест потребує зовсім іншого діагностичного підходу.

** Сказати “просто додайте затримку” як типовий виправлення для лускатості. ** Замість цього скажіть: «Давайте перевіримо, чи автоматичне очікування вже покриває це, або чи справжня проблема є твердженням, що перевіряє неправильну умову» — довільне очікування часто просто папір над умовою гонки замість розв’язання її.

**Сказати “селектор не працює” без пояснення чому. ** Замість цього можна сказати: « цей селектор прив’ язано до класу стилю, який часто змінюється — замість цього використаємо спеціальний атрибут тестування » — це визначає справжню нестабільність, а не вважає помилку випадковою.

Краткий справочник

Term	How to use it
selector	”Use a data-testid selector instead of a styling class.”
auto-waiting	”Auto-waiting retries this assertion before timing out — no manual wait needed.”
flaky test	”This test is flaky under CI load, likely a race condition.”
fixture	”We load a fixture instead of depending on live API data.”
network stubbing	”We stubbed the payment API so no real charge happens during tests.”
test isolation	”Each test should set up its own state, not depend on a prior test.”

Ключеві моменти

• Відрізняти неправильно виконаний тест від неправильно виконаного — неправильні помилки вимагають діагностики причин (час, умови перегонів), а не просто повторення.
• Віддавати перевагу виділеним атрибутам тестування перед селекторами, заснованими на стилях, оскільки останні порушуються кожного разу, коли дизайнер змінює назву класу.
• Довіряти автоматичному очікуванню перед тим, як звертатися до довільних вручну очікувань, які часто маскують, а не виправляють справжню проблему з часовими параметрами.
• Використовуйте інструменти і мережеві засувки, щоб тести були відтворювані і незалежні від стану сервера.
• Розглядати ізоляцію тестів як принцип дизайну, який не підлягає обговоренню — тести, які залежать від порядку виконання, розмивають довіру до всього набору.

Навігація Nuance: англійська для тестування співпраці

Будьмо відвертими – тестування не просто про запуск коду; це фундаментально спільний процес. Коли ви працюєте з колегами, особливо з тими, чия перша мова не англійська, точність у спілкуванні є абсолютно критичною. Недостатньо просто сказати, що тест * робить *; вам потрібно сформулювати * чому * він це робить, і як його поведінка відповідає очікуванням. Це часто включає в себе тонкий зсув у словнику і фразування, що може значно вплинути на якість зворотнього зв’язку і загальну ефективність команди.

Розглянемо цей сценарій: Сара, нова розробниця проекту, надсилає PR, у якому міститься тест Cypress, призначений для перевірки введення користувачем у реєстраційній формі. Рецензент, Марк, залишає коментар: «Цей селектор є крихким — він сильно залежить від конкретного текстового вмісту. Розгляньте можливість використання більш надійних локалізацій, таких як атрибути даних або властивості CSS.» Хоча цей коментар технічно правильний, його можна розглядати як критику. Сара може почувати себе в обороні, не впевнена, чому селектор хибний і як вона може його поліпшити. Більш конструктивним підходом було б: «Я розумію вашу занепокоєність щодо крихкості селекторів. Я використовую атрибути data-id для вхідних полів, щоб забезпечити стабільнішу ціль. Чи можете ви провести мене через деякі альтернативні стратегії локалізації, які також можуть бути стійкими до змін у інтерфейсі користувача?» Це змінює фокус з простого виявлення проблеми на * співпрацю * у пошуку рішення.

Аналогічно, при описі тріщини - поширене розчарування з тестами end-to-end - уникати надмірно технічного жаргону. Замість того, щоб сказати « перевірка не виконується належним чином через затримку мережі », спробуйте сказати: « Цей тест іноді зазнає невдачі, ймовірно, через відхилення у часі відповіді сервера. Ми повинні дослідити, чи можемо ми ввести тайм-аути або механізми повторних спроб. » Такі фрази, як «перервно» і «відмінності у часі відповіді» є набагато більш доступними і сприяють спільному розумінню проблеми. Під час написання описів PR, будьте чіткими щодо * намірів *, які стоять за тестом: « Цей тест перевіряє, чи нова реєстрація користувача успішно створює обліковий запис і надсилає привітальну електронну пошту ». Метою є надання чіткої картини для кожного, хто читає цей текст — а не просто ще одного розробника, який володіє технічною англійською мовою.

Нарешті, пам’ятайте, що самі твердження користуються обережною формулюванням. Замість того, щоб сказати « елемент існує », що технічно є правдою, але не відповідає контексту, спробуйте сказати: « Кнопка надсилання форми реєстрації буде видимою і увімкненою, якщо всі потрібні поля буде заповнено ». Таким чином ви повідомите про те, що елемент було перевірено, а не лише про те, що він існує.

// Example Cypress code demonstrating a robust selector strategy
it('should register a new user', () => {
  cy.visit('/register');
  cy.get('[data-id="username"]').type("testuser");
  cy.get('[data-id="email"]').type("test@example.com");
  cy.get('#submitButton').click();
  cy.contains('Welcome, testuser!').should('be.visible');
});

Цей приклад демонструє використання атрибута data-id як стабільнішого селектору, ніж покладатися виключно на текстовий вміст в самому полі вводу. Це практичне застосування словника, обговореного вище - демонструючи активний підхід до створення стійких і зрозумілих тестів.