Cypress
Last updated
Last updated
Cypress — чудовий інструмент тестування E2E. Ось кілька вагомих причин розглянути це:
Можлива ізольована установка.
Поставляється з підтримкою TypeScript із коробки.
Забезпечує гарний інтерактивний досвід налагодження google chrome. Це дуже схоже на те, як розробники інтерфейсу користувача здебільшого працюють вручну.
Має поділ команди на виконання, що забезпечує більш потужне налагодження та тестування стабільності (докладніше про це нижче).
Містить неявні твердження для забезпечення більш значущого досвіду налагодження з менш крихкими тестами (докладніше про це в порадах нижче).
Надає можливість легко створювати та спостерігати за серверними XHR, не змінюючи код програми (докладніше про це в порадах нижче).
Кроки, надані в цьому процесі інсталяції, дадуть вам гарну папку e2e
, яку ви можете скопіювати/вставити або як шаблон для вашої організації.
Ті самі дії представлені у відеоформаті на моєму .
Створіть каталог e2e, встановіть cypress, TypeScript і налаштуйте файли конфігурації typescript і cypress:
Ось кілька причин для створення окремої папки
e2e
спеціально для cypress:
Створення окремого каталогу для e2e
полегшує ізоляцію його залежностей package.json
від решти вашого проекту. Це призводить до зменшення конфліктів залежностей.
Фреймворки тестування мають звичку забруднювати глобальний простір імен такими речами, як describe
it
expect
. Найкраще зберігати tsconfig.json
і node_modules
e2e у цій спеціальній папці e2e
, щоб запобігти глобальним конфліктам визначення типу.
Додайте кілька сценаріїв до файлу e2e/package.json
:
Напишіть свій перший тест у cypress/integration/basic.ts
:
Тепер запустіть npm run cypress:open
під час розробки та npm run cypress:run
на вашому сервері збірки 🌹
У папці e2e
у вас є такі файли:
/cypress.json
: Налаштувати cypress. За умовчанням порожній, і це все, що вам потрібно.
Підпапки /cypress
:
/integration
: усі ваші тести.
Не соромтеся створювати тести у вкладених папках для кращої організації, напр. /someFeatureFolder/something.spec.ts
.
створіть файл /cypress/integration/first.ts
з таким вмістом:
Відкрийте IDE cypress за допомогою такої команди.
І виберіть тест для запуску.
Ви можете запустити тести Cypress у ci режимі за допомогою наступної команди.
Тести Cypress скомпільовані / упаковані та запускаються в браузері. Тому сміливо імпортуйте будь-який код проекту у свій тест.
Наприклад, ви можете поділитися значеннями ідентифікатора між інтерфейсом користувача та тестами, щоб переконатися, що селектори CSS не зламаються:
Створення об’єктів, які надають зручний вказівник для всіх взаємодій, які різні тести повинні робити зі сторінкою, є загальною умовою тестування. Ви можете створювати об’єкти сторінки за допомогою класів TypeScript із геттерами та методами, наприклад.
Cypress поставляється з (вбудованими) бібліотеками тверджень chai та chai-query, які допомагають тестувати веб-сторінки. Ви використовуєте їх із командою .should
, яка передається в ланцюжок як рядок, замінюючи .to.foo
на should('foo')
, наприклад. з chai-jquery ви використовуєте expect($(#foo)).to.have.text('something')
, з cypress це було cy.get('#foo').should('have.text', 'something')
:
Ви отримуєте інтелектуальну інформацію для ланцюжків
should
, оскільки Cypress поставляється з правильними визначеннями TypeScript 👍🏻
Якщо ви хочете щось складне, ви можете навіть використати should(callback)
і, наприклад,
ПОРАДА: cypress також виконує автоматичні повторні спроби під час зворотного виклику, тому вони так само вільні від розшарування, як і стандартні цепочки рядків.
Кожен виклик функції в ланцюжку Cypress є command
. Команда should
є твердженням. Традиційно починати окрему category ланцюжків і дій окремо, наприклад.
Деякі інші бібліотеки оцінюють і запускають код одночасно. Ці бібліотеки змушують вас мати єдиний ланцюжок, який може бути кошмаром для налагодження з перемішаними селекторами та твердженнями.
Команди Cypress по суті є деклараціями для середовища виконання cypress для виконання команд пізніше. Прості слова: Cypress робить це легше.
contains
for easier queryingНижче показано приклад:
Cypress автоматично чекатиме (і повторюватиме спроби) для багатьох асинхронних речей, наприклад.
Це позбавляє вас від необхідності постійно додавати довільну логіку очікування (і повторних спроб) у потік тестового коду.
Cypress має концепцію неявного твердження. Вони спрацьовують, якщо майбутня команда має помилку через попередню команду. наприклад наступне буде помилкою в contains
(після автоматичних повторних спроб, звичайно), оскільки нічого знайденого не можна click
:
У традиційних фреймворках ви отримаєте жахливу помилку, наприклад, click
не існує на null
. У Cypress ви отримуєте гарну помилку #foo
не містить Submit
. Ця помилка є формою неявного твердження.
Багато тестів традиційно були крихкими через усі довільні тайм-аути, необхідні для XHR, які створює програма. cy.server
полегшує це
створити псевдонім для внутрішніх викликів
дочекатися їх появи
Ви також можете легко імітувати відповідь на запит за допомогою route
:
Ви можете стверджувати запити без mocking, використовуючи route
onRequest
/ onResponse
, наприклад.
Ви можете використовувати wait
, щоб призупинити тест на деякий час, наприклад. щоб перевірити екран автоматичного сповіщення "Ви збираєтеся вийти з системи":
Однак рекомендується імітувати час за допомогою cy.clock
і пересилати час за допомогою cy.tick
.
Ви також можете використовувати cypress для модульного тестування коду програми в ізоляції.
Якщо ви використовуєте модульне тестування модулів у своїй програмі, ви можете надати макети за допомогою cy.stub
, наприклад. якщо ви хочете переконатися, що navigate
викликається у функції foo
:
foo.ts
Ви можете зробити це, як у some.spec.ts
:
Коли ви викликаєте команду cypress (або твердження), наприклад. cy.get('#something')
, функція негайно повертає результат без фактичного виконання дії. Що він робить, це інформує тестувальника cypress, що вам потрібно буде виконати дію (у цьому випадку get
) у якийсь момент.
По суті, ви створюєте список команд, який потім буде виконувати ранер. Ви можете перевірити цю команду - відокремлення виконання за допомогою простого тесту, зауважте, що ви побачите, що оператори start / between / end
console.log
виконуються безпосередньо перед тим, як програма запуску почне виконувати команди:
Це розділення виконання команд має дві великі переваги:
Виконувач може виконувати команди в flake-resistant спосіб з автоматичними повторними спробами та неявними твердженнями.
Дозволяє писати асинхронний код у синхронному режимі без постійного chaining, що призводить до складності підтримки коду.
Автоматичні snapshots + журнал команд, згенерований тестом cypress, чудово підходять для налагодження. При цьому ви можете призупинити виконання тесту, якщо хочете.
Спочатку переконайтеся, що у вас відкриті інструменти розробника Chrome (з любов’ю — dev tools) у програмі тестування («CMD + ALT + i» на mac / F12
на Windows). Коли інструменти розробника відкриються, ви можете повторно запустити тест, і інструменти розробника залишаться відкритими. Якщо у вас відкриті інструменти розробника, ви можете призупинити виконання тесту двома способами:
Точки зупинки коду програми: використовуйте оператор debugger
у коді програми, і програма виконання тестів зупиниться на цьому, як і стандартна веб-розробка.
Точки зупинки тестового коду: ви можете використати команду .debug()
, і виконання тесту cypress зупиниться на ній. Крім того, ви можете використати оператор debugger
у зворотному виклику команди .then
, щоб викликати паузу. наприклад .then(() => { debugger })
. Ви навіть можете використовувати його, щоб отримати якийсь елемент cy.get('#foo').then(($ /* посилання на елемент dom */) => { debugger; })
або мережевий виклик, наприклад. cy.request('https://someurl').then((res /* відповідь мережі */) => { налагоджувач });
. Однак ідіоматичним способом є cy.get('#foo').debug()
, а потім, коли програму тестування призупинено на debug
, ви можете натиснути get
у журналі команд, щоб автоматично console.log
будь-яка інформація, яка вам може знадобитися про команду .get('#foo')
(та аналогічно для будь-яких інших команд, які ви хочете налагодити).
сценарій npm для запуску сервера (він же сервер)
кінцева точка, щоб перевірити, чи завантажився сервер (він же старт)
сценарій npm для початку тестування (він же тест)
Приклад package.json:
Повний список ланцюжків доступний тут:
Якщо вам потрібно запустити локальний сервер перед виконанням тестів, ви можете додати start-server-and-test
як залежність. Це вимагає наступних аргументів
Веб-сайт:
Напишіть свій перший cypress тест (подає чудову екскурсію по cypress IDE):
Налаштування середовища CI (наприклад, наданий образ докера, який одразу працює з cypress run
):
Рецепти (перелічує рецепти з описами. Натисніть на заголовки, щоб перейти до вихідного коду рецепту):
Візуальне тестування:
Додатково встановіть baseUrl
у cypress.json, щоб
Покриття коду за допомогою Cypress: