Англійська для Cypress Testing

Кінець-до-кінця тестування з Cypress має свій власний словник для опису того, як тести взаємодіють з запущеною програмою — «команда», «перехоплення» і «флаке» мають певне технічне значення. Команди, які описують кожен невдалий тест як «флаки» без подальших деталей, марнують час на повторне запуску тестів замість виправлення основних причин. Цей підручник містить умови для обговорення тестів Cypress.

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

** Команда ** — ланцюговий виклик Cypress API ( cy.get, cy.click, cy.type ), який вставляє в чергу дію або твердження для виконання у тестованій програмі. “Зв’ язати команду cy.get з твердженням should замість очікування вручну — Cypress автоматично повторює спроби, поки не з’ явиться елемент.”

** Fixture ** — статичний файл (зазвичай JSON), що містить імітаційні дані, завантажені до тесту для заміни передбачуваної відповіді API.

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

** Перехоплення ** — команда Cypress ( cy.intercept ), яка перехоплює або перевіряє мережеві запити, надаючи змогу тестам керувати відповідями API або чекати завершення запиту. “Ми додали перехоплення на кінцевій точці отримання, тому тест очікує на розв’ язання реального мережевого виклику перед повідомленням на сторінці підтвердження.”

** Флакі тест ** — тест, який проходить і зазнає невдачі неодноразово протягом виконань без будь- яких змін у коді, зазвичай, через проблеми з часом, необроблену поведінку асинхронності або забруднення тесту. “Це не є тестом на неточність у неясному сенсі — він не спрацьовує, особливо, коли відповідь API триває довше, ніж закодована тривалість анімації.”

** Ізоляція тестів ** — практика забезпечення того, щоб кожен тест починався з чистого, незалежного стану, так що дії одного тесту не впливають на результати інших.

• “Ми втратили ізоляцію тестів, коли почали ділитися одним користувачем, що має право на проходження тестів — тепер невдачі в одному тесті перетворюються на нев’ язні.” *

** Нетипова команда ** — команда Cypress, яку можна використовувати знову і знову, визначена у cypress/support/commands.js, використовується для інкапсулювання повторюваних багатокрокових дій, таких як входження до системи. “Замість повторення п’яти кроків входу в систему в кожному тесті, ми обгорнули його в нетипову команду під назвою cy.login.”

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

• Чи це насправді лускатий, або це постійно не вдається під певними умовами?»
• Чи перехопили ми цей запит, чи тест вдаряє по реальному бекенду?»
• «Давайте перевіримо ізоляцію тесту — чи це несправність, викликана станом, залишеним з попереднього тесту?»
• “Чи слід використовувати цю команду? Ми повторюємо цю ж послідовність в чотирьох інших тестах»
• Чи є цей фільм дійсно подібним до «Смертельного пошуку»?»

Приклади висловлювань

Звітування про невдалу перевірку точно: “Ця перевірка зазнає невдачі лише у CI, а не локально, і лише коли вона запускається після завершення пакету вивантаження — це вказує на залишок стану з попередньої перевірки, а не на справжню проблему з неправильним часом.”

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

Обговорення підтримки тестів з колегою:

• “Давайте витягнемо повторювані кроки реєстрації та налаштування кошика у нетипові команди — зараз кожен новий тест копіює п’ ятнадцять рядків налаштування, і будь- які зміни у потоці реєстрації означають оновлення всіх з них.” *

Професійні поради

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

Практичні вправи

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

Складання графіків: практична робота для студентів

Для не-англомовних носіїв англійської мови, які стикаються з Cypress тестуванням, це не тільки про знання *команд * - cy.get(), cy.click(), і т.д. Це ефективне спілкування в команді розробників, що сильно покладається на точну мову і спільні цикли зворотнього зв’язку. Часто нерозуміння виникають просто через тонкі відмінності в тому, як виражаються поняття. Розглянемо деякі типові ситуації, у яких використання правильної фрази може значно поліпшити ваш робочий процес і забезпечити, щоб всі були на одній сторінці.

Одна з найчастіших ситуацій — під час перегляду коду. Отримавши коментар на кшталт «Цей тест недостатньо надійний» може бути розчаруванням без контексту. Замість того, щоб просто прийняти це, спробуйте отримати більше інформації. Кращий підхід був би: “Чи можете ви розібратися, що саме робить цей тест менш надійним? Чи є конкретні сценарії, які ми не охоплюємо, або твердження не спрацьовує за певних умов?” Аналогічно, опис PR повинен чітко сформулювати * чому * ви робите зміни. Сказати «Виявлена помилка» недостатньо; поясніть проблему, рішення і те, як вона була перевірена — «Вреалізовано механізм повторних спроб для обробки нерегулярних мережевих проблем, які спричиняли невдачу подачі форми. Перевірено цей виправлення за допомогою моделювання повільного з’ єднання за допомогою cy.request() і підтвердження успішного передачі даних. « Цей рівень деталізації показує розуміння і зменшує неоднозначність для ваших переглядачів. Крім того, при обговоренні * неоднозначних тестів * (тести, які періодично проходять або провалюються), уникайте нечітких термінів, таких як « це не працює ». Замість цього використовуйте такі фрази, як « Цей тест виявляє непослідовну поведінку » або « Нам потрібно дослідити кореневу причину цієї періодичної невдачі »

Інша область, де точна мова має значення, це розмови Slack. Уявіть обговорення про невдалий тест: « Це просто не працює! » Це не надає ніякої корисної інформації. Більш продуктивною відповіддю буде: «Команда cy.get() не постійно знаходить елемент. Я підозрюю, що можуть бути проблеми з селекторами CSS або зміни у інтерфейсі користувача, які впливають на його видимість. » Поділитися вашими спостереженнями — навіть якщо вони здаються очевидними — допоможе іншим зрозуміти проблему і, можливо, швидше визначити рішення. Пам’ ятайте, коротка і конкретна мова є ключем до ефективної співпраці.

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

cy.task('slow_network', {duration: 5000}) // Simulate slow network conditions for testing

Ця команда, використовуючи cy.task(), демонструє, як конкретна технічна дія часто описується - не просто як “тестування мережевих проблем”, а як навмисне створення сценарію для спостереження за поведінкою. Це про комунікацію наміру і методології.