Наскрізне тестування за допомогою GitLab CI/CD та WebdriverIO

Програми для перегляду чудові: для кожного запиту на злиття (або гілки, з цього приводу) новий код можна скопіювати та розгорнути у свіжому виробничому середовищі, зменшуючи зусилля для оцінки впливу змін. Таким чином, коли ми використовуємо менеджер залежностей, такий як Dependencies.io, він може подати запит на злиття з оновленою залежністю, і відразу буде зрозуміло, що додаток все ще може бути належним чином побудований та розгорнутий. Зрештою, ви бачите, як він працює!

тестування

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

У цій статті ми обговоримо, як писати такі наскрізні тести, і як налаштувати GitLab CI/CD для автоматичного запуску цих тестів за вашим новим кодом на основі розгалуження. Для обсягу цієї статті ми проведемо вас через процес налаштування GitLab CI/CD для наскрізного тестування програм на основі JavaScript за допомогою WebdriverIO, але загальна стратегія повинна переноситися на інші мови. Ми вважаємо, що ви знайомі з GitLab, GitLab CI/CD, Review Apps і запускаєте свій додаток локально, наприклад, на localhost: 8000 .

Що перевірити

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

Селен та WebdriverIO

Селен - це програмне забезпечення, яке може керувати веб-браузерами, наприклад, щоб змусити їх відвідувати певну URL-адресу або взаємодіяти з елементами на сторінці. Нею можна програмно керувати з різних мов програмування. У цій статті ми будемо використовувати прив’язки WebdriverIO JavaScript, але загальна концепція повинна досить добре переноситися на інші мови програмування, що підтримуються Selenium.

Тести письма

Функції опису, його та браузера забезпечуються WebdriverIO. Давайте розберемо їх по одному.

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

Функція, яку він визначає, індивідуальний тест.

Об'єктом браузера є спеціальний соус WebdriverIO. Він надає більшість методів API WebdriverIO, які є ключем до керування браузером. У цьому випадку ми можемо використовувати browser.url, щоб відвідати/сторінку, яка не існує, щоб потрапити на нашу сторінку 404. Потім ми можемо використовувати browser.getUrl, щоб переконатися, що поточна сторінка справді знаходиться у вказаному нами місці. Для взаємодії зі сторінкою ми можемо просто передати селектори CSS браузеру browser.element, щоб отримати доступ до елементів на сторінці та взаємодіяти з ними - наприклад, натиснути на посилання назад на домашню сторінку.

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

Запуск локально

За мить ми дійдемо до запуску вищезазначеного тесту на CI/CD. Однак під час написання тестів корисно, якщо вам не доведеться чекати, поки ваші трубопроводи досягнуть успіху, щоб визначити, чи виконують вони те, що ви очікуєте від них. Іншими словами, давайте запускати його локально.

Переконайтеся, що ваш додаток працює локально. Якщо ви використовуєте Webpack, ви можете використовувати плагін Webpack Dev Server WebdriverIO, який автоматично запускає сервер розробки перед виконанням тестів.

Документація WebdriverIO містить огляд усіх параметрів конфігурації, але найпростіший спосіб розпочати - почати з конфігурації WebdriverIO за замовчуванням, яка надає огляд усіх доступних опцій. Два варіанти, які зараз будуть найбільш актуальними, - це параметр специфікацій, який є масивом шляхів до ваших тестів, і параметр baseUrl, який вказує на те, де працює ваша програма. І нарешті, нам потрібно буде повідомити WebdriverIO, в яких браузерах ми хотіли б запускати наші тести. Це можна налаштувати за допомогою опції можливостей, яка являє собою масив імен браузера (наприклад, firefox або chrome). Рекомендується встановити селен-помічник для виявлення всіх встановлених браузерів:

Але звичайно, проста конфігурація config.capabilities = ['firefox'] також буде працювати.

Якщо ви встановили WebdriverIO як залежність (npm install --save-dev webdriverio), ви можете додати рядок до властивості скриптів у вашому package.json, який запускає wdio із шляхом до вашого файлу конфігурації як значення, наприклад:

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

Налаштування GitLab CI/CD

Що підводить нас до захоплюючої частини: як ми запускаємо це в GitLab CI/CD? Для цього нам потрібно зробити дві речі:

  1. Налаштуйте завдання CI/CD, які фактично мають доступний браузер.
  2. Оновіть нашу конфігурацію WebdriverIO, щоб використовувати ці браузери для відвідування програм огляду.

Для обсягу цієї статті ми визначили додаткову перевірку впевненості на етапі CI/CD, яка виконується після етапу, який розгортає програму огляду. Він використовує вузол: останнє зображення Docker. Однак WebdriverIO запускає фактичні браузери для взаємодії з вашим додатком, тому нам потрібно їх встановити та запустити. Крім того, WebdriverIO використовує Selenium як загальний інтерфейс для управління різними браузерами, тому нам також потрібно встановити та запустити Selenium. На щастя, проект Selenium забезпечує зображення Docker автономно-firefox та автономно-chrome, які забезпечують саме те, що для Firefox та Chrome, відповідно. (Оскільки Safari та Internet Explorer/Edge не є відкритими і не доступні для Linux, ми, на жаль, не можемо використовувати їх у GitLab CI/CD).

GitLab CI/CD полегшує пов’язування цих зображень із нашими завданнями перевірки впевненості за допомогою властивості служби, що робить сервер Selenium доступним під іменем хосту на основі імені зображення. Тоді наша конфігурація роботи виглядає приблизно так:

І так само для Chrome:

Тепер, коли у нас є робота для запуску наскрізних тестів, нам потрібно сказати WebdriverIO, як підключитися до серверів Selenium, що працюють поряд з ним. Ми вже обдурили трохи вище, передавши значення параметра host як аргумент для npm run check-check у командному рядку. Однак нам все-таки потрібно повідомити WebdriverIO, який браузер доступний для використання.

GitLab CI/CD робить доступними ряд змінних з інформацією про поточне завдання CI. Ми можемо використовувати цю інформацію для динамічного налаштування конфігурації WebdriverIO відповідно до запущеного завдання. Більш конкретно, ми можемо сказати WebdriverIO, на якому браузері виконувати тест, залежно від назви поточного завдання. Ми можемо зробити це у файлі конфігурації WebdriverIO, який ми назвали вище wdio.conf.js:

Так само ми можемо повідомити WebdriverIO, де запущений додаток для огляду - у цьому прикладі він увімкнений
.flockademic.com:

І ми можемо переконатися, що наша локальна конфігурація використовується лише тоді, коли не працює в CI, використовуючи if (! Process.env.CI). Це в основному всі інгредієнти, необхідні для проведення наскрізних тестів на GitLab CI/CD!

Для підсумку наш конфігураційний файл .gitlab-ci.yml виглядає приблизно так:

Що далі

Якщо ви налаштовуєте це для себе і хочете зазирнути до робочої конфігурації виробничого проекту, дивіться:

  • Flockademic’s wdio.conf.js
  • Flockademic’s .gitlab-ci.yml
  • Тести Flockademic

WebdriverIO може зробити набагато більше. Наприклад, ви можете налаштувати screenshotPath, щоб повідомити WebdriverIO робити знімок екрана, коли тести не вдаються. Тоді скажіть GitLab CI/CD зберігати ці артефакти, і ви зможете побачити, що пішло не так у GitLab.