How Guru’s Engineers Use Cypress for Better Burn Testing
Потрібен кращий спосіб для проведення тестування на згорання? Два наших фронт-енд інженери знайшли спосіб використовувати Cypress, щоб поліпшити спосіб, яким вони займаються контролем якості.
Ми всі про обмін знаннями в Guru, і коли ми відкриваємо щось нове та корисне, ми хочемо, щоб світ це знав! Наша інженерна команда використовує Cypress у процесі тестування та контролю якості. Вони знайшли новий спосіб проведення кращих тестів на згорання і хочуть поділитися своїм новим та поліпшеним процесом з іншими інженерами та тестувальниками.
Протягом минулого року ми зосередилися на збільшенні нашого покриття тестування — зокрема, на тестуванні з кінця в кінець, яке забезпечує правильне функціонування різних частин нашого продукту під час внесення оновлень коду. Для цього виду тестування ми використовуємо інструмент під назвою Cypress, який імітує поведінку користувача з нашим веб-додатком та розширенням Google Chrome. Цей тестовий пакет запускається на кожен запит на злиття, щоб забезпечити, що новий код не руйнує речі в нашому інтерфейсі користувача. Ми також хочемо заблокувати випуски, якщо наш пакет Cypress зазнає невдачі на нашій продукційній гілці.
Що ми шукаємо в традиційному тестуванні
Одна проблема, з якою ми стикалися — це спостереження за збоєм деяких наших тестів, але не з причин, пов'язаних з інтерфейсом або кодом. Отже, як Cypress допомагає нам у цих випадках? Ми змушуємо Cypress діяти як користувач, чию поведінку ми можемо визначити. Є кілька змінних, які можуть привести до того, що Cypress скаже нам про збій, але з точки зору користувача нічого не здається неправильним.
Наприклад, може бути тест, який говорить: "Перейти до цієї частини веб-додатку > Додати нову картку Guru > Очікувати побачити стан після створення". Якщо стан завантаження створення картки затримується на мілісекунду занадто довго, і Cypress починає шукати стан після створення до того, як його там немає, цей тест може зазнати невдачі (більшість часу, однак, цей тест пройде). Якщо він проходить один раз на запит на злиття, ми можемо об'єднати код, який іноді може давати збій. Але ми не будемо знати, чи це так; успішний тест не є гарантією того, що код правильний.
Такий вид ситуації знижує надійність нашого покриття тестування. В результаті, коли у нашому процесі розгортання виникає збій тесту, нам потрібно перевірити, чи це проблема з інтерфейсом — чи з тестом. Щоб виправити це, ми почали думати про способи виявлення, якщо тест може давати збій до того, як він потрапить до нашої гілки продукційного коду.
Як допомагає тестування на згорання
Вводимо тестування на згорання. Тестування на згорання — це процес, який використовується для тестування чогось під більш суворими або екстремальними умовами. Це також іноді називають стрес-тестуванням або тестуванням на навантаження, в залежності від методу чи конкретної області, що тестується.
В Guru ми використовуємо тестування на згорання як частину нашого пакету Cypress для будь-яких нових або змінених тестів, які додаються до нашої кодової бази. Перш ніж ці тести можуть бути злиті, ми запускаємо їх кілька разів поспіль, і всі вони повинні пройти, щоб перейти до наступного етапу в нашій збірці CircleCI.
Цей етап відбувається відразу перед запуском всього тестового пакету Cypress. Перевага цього порядку полягає в тому, що якщо наш етап тестування на згорання призводить до збою, ми можемо відзначити весь перевірку як збій рано. Пропуск решти пакету дозволяє нам заощадити час і зменшити кількість циклів, які можуть знадобитися для забезпечення того, що нові тести є такими надійними та стійкими до помилок, якими нам потрібно, щоб вони були.
Щоб знайти файли, які ми шукаємо, ми використовуємо git diff на поточній гілці і передаємо вивід як параметр до інструменту під назвою cypress-repeat, який дозволяє нам запускати ці тести будь-яку зазначену кількість разів, ефективно додавши тестування на згорання як етап у нашому тестуванні з кінця в кінець.
Результат
Зміна цього в нашій плані тестування дало деякі досить значні позитивні результати. Для нас додавання тестування на згорання може зменшити час, необхідний для виявлення ненадійних тестів, до 30 хвилин. Це також покращує час реагування для додавання нової функціональності. Оскільки нові додані тести тепер запускаються першими, вони дозволяють нам перевірити стабільність, перш ніж переходити до решти процесу складання.
Загалом, наша постійна увага до того, щоб зробити наші процеси тестування більш ефективними та надійними, підвищує впевненість усієї інженерної команди в швидкому запуску нових функцій. Ми швидше виправляємо помилки і робимо більш простим роботу з усіма нашими кодовими базами. Сподіваємось, що цей пост допоможе іншим користувачам Cypress створювати кращі тести та всім командам працювати більш ефективно.
Ми всі про обмін знаннями в Guru, і коли ми відкриваємо щось нове та корисне, ми хочемо, щоб світ це знав! Наша інженерна команда використовує Cypress у процесі тестування та контролю якості. Вони знайшли новий спосіб проведення кращих тестів на згорання і хочуть поділитися своїм новим та поліпшеним процесом з іншими інженерами та тестувальниками.
Протягом минулого року ми зосередилися на збільшенні нашого покриття тестування — зокрема, на тестуванні з кінця в кінець, яке забезпечує правильне функціонування різних частин нашого продукту під час внесення оновлень коду. Для цього виду тестування ми використовуємо інструмент під назвою Cypress, який імітує поведінку користувача з нашим веб-додатком та розширенням Google Chrome. Цей тестовий пакет запускається на кожен запит на злиття, щоб забезпечити, що новий код не руйнує речі в нашому інтерфейсі користувача. Ми також хочемо заблокувати випуски, якщо наш пакет Cypress зазнає невдачі на нашій продукційній гілці.
Що ми шукаємо в традиційному тестуванні
Одна проблема, з якою ми стикалися — це спостереження за збоєм деяких наших тестів, але не з причин, пов'язаних з інтерфейсом або кодом. Отже, як Cypress допомагає нам у цих випадках? Ми змушуємо Cypress діяти як користувач, чию поведінку ми можемо визначити. Є кілька змінних, які можуть привести до того, що Cypress скаже нам про збій, але з точки зору користувача нічого не здається неправильним.
Наприклад, може бути тест, який говорить: "Перейти до цієї частини веб-додатку > Додати нову картку Guru > Очікувати побачити стан після створення". Якщо стан завантаження створення картки затримується на мілісекунду занадто довго, і Cypress починає шукати стан після створення до того, як його там немає, цей тест може зазнати невдачі (більшість часу, однак, цей тест пройде). Якщо він проходить один раз на запит на злиття, ми можемо об'єднати код, який іноді може давати збій. Але ми не будемо знати, чи це так; успішний тест не є гарантією того, що код правильний.
Такий вид ситуації знижує надійність нашого покриття тестування. В результаті, коли у нашому процесі розгортання виникає збій тесту, нам потрібно перевірити, чи це проблема з інтерфейсом — чи з тестом. Щоб виправити це, ми почали думати про способи виявлення, якщо тест може давати збій до того, як він потрапить до нашої гілки продукційного коду.
Як допомагає тестування на згорання
Вводимо тестування на згорання. Тестування на згорання — це процес, який використовується для тестування чогось під більш суворими або екстремальними умовами. Це також іноді називають стрес-тестуванням або тестуванням на навантаження, в залежності від методу чи конкретної області, що тестується.
В Guru ми використовуємо тестування на згорання як частину нашого пакету Cypress для будь-яких нових або змінених тестів, які додаються до нашої кодової бази. Перш ніж ці тести можуть бути злиті, ми запускаємо їх кілька разів поспіль, і всі вони повинні пройти, щоб перейти до наступного етапу в нашій збірці CircleCI.
Цей етап відбувається відразу перед запуском всього тестового пакету Cypress. Перевага цього порядку полягає в тому, що якщо наш етап тестування на згорання призводить до збою, ми можемо відзначити весь перевірку як збій рано. Пропуск решти пакету дозволяє нам заощадити час і зменшити кількість циклів, які можуть знадобитися для забезпечення того, що нові тести є такими надійними та стійкими до помилок, якими нам потрібно, щоб вони були.
Щоб знайти файли, які ми шукаємо, ми використовуємо git diff на поточній гілці і передаємо вивід як параметр до інструменту під назвою cypress-repeat, який дозволяє нам запускати ці тести будь-яку зазначену кількість разів, ефективно додавши тестування на згорання як етап у нашому тестуванні з кінця в кінець.
Результат
Зміна цього в нашій плані тестування дало деякі досить значні позитивні результати. Для нас додавання тестування на згорання може зменшити час, необхідний для виявлення ненадійних тестів, до 30 хвилин. Це також покращує час реагування для додавання нової функціональності. Оскільки нові додані тести тепер запускаються першими, вони дозволяють нам перевірити стабільність, перш ніж переходити до решти процесу складання.
Загалом, наша постійна увага до того, щоб зробити наші процеси тестування більш ефективними та надійними, підвищує впевненість усієї інженерної команди в швидкому запуску нових функцій. Ми швидше виправляємо помилки і робимо більш простим роботу з усіма нашими кодовими базами. Сподіваємось, що цей пост допоможе іншим користувачам Cypress створювати кращі тести та всім командам працювати більш ефективно.
Досвідчіть силу платформи Guru особисто – пройдіть наш інтерактивний тур продуктом
