Запуск HN: DeploySentinel (YC S22) - наскрізне тестування, яке не згортається

Запуск HN: DeploySentinel (YC S22) - наскрізне тестування, яке не згортається 13 балів від mikeshi42 1 годину тому | приховати | минуле | улюблений | 10 коментарів Привіт, HN, тут Майкл і Воррен – співзасновники DeploySentinel(). Ми робимо наскрізне тестування простішим і надійнішим.

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

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

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

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

Ми надаємо вам можливість перевіряти знімки DOM, мережеві події та журнали консолі для будь-якого кроку, виконаного під час тестового запуску Cypress у CI, щоб краще зрозуміти, чому певний тест може бути невдалим. Це як Fullstory/LogRocket, але для збоїв CI замість виробничих помилок. (Ми починаємо з тестування Cypress і плануємо продовжити.)

Наш інструмент інтегрується з Cypress через їхній плагін API, тож ми можемо підключати та записувати тести в CI лише за допомогою встановлення NPM і 2 рядків коду. Звідти ми можемо підключатися до подій Cypress/Mocha, щоб фіксувати все, що відбувається в програмі тестування (наприклад, коли починається тест, коли запускається команда, коли знайдено елемент тощо), а також відкривати порт протоколу налагодження. з браузером для прослуховування подій мережі та консолі. Коли набір тестів запущено, налагоджувач систематично збирає те, що відбувається під час тестування, і завантажує інформацію (мінус будь-які налаштовані користувачем цензуровані події) після завершення кожного тесту.

Хоча це може здатися схожим на вставлення LogRocket/FullStory у ваш набір тестів, насправді є чимало відмінностей. Найбільш зручним є те, що ці інструменти зазвичай мають низьку пропускну здатність, яка добре працює для людського трафіку, що взаємодіє з веб-програмами на швидкості людини, але ламається, коли справа доходить до трафіку від паралелізованих тестувальників, які взаємодіють із веб-програмами на машинній швидкості. Інші незначні деталі пов’язані з тим, що ми пов’язуємо повтори з тестовими метаданими на відміну від метаданих користувача, маємо повний доступ до всіх мережевих запитів/повідомлень консолі, виданих під час тестування на рівні браузера, та індексуємо нашу прочитану інформацію на основі тестових команд, а не часових позначок (час ненадійна концепція в тестуванні!).

Один раз на п...

Запуск HN: DeploySentinel (YC S22) - наскрізне тестування, яке не згортається
Запуск HN: DeploySentinel (YC S22) - наскрізне тестування, яке не згортається 13 балів від mikeshi42 1 годину тому | приховати | минуле | улюблений | 10 коментарів Привіт, HN, тут Майкл і Воррен – співзасновники DeploySentinel(). Ми робимо наскрізне тестування простішим і надійнішим.

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

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

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

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

Ми надаємо вам можливість перевіряти знімки DOM, мережеві події та журнали консолі для будь-якого кроку, виконаного під час тестового запуску Cypress у CI, щоб краще зрозуміти, чому певний тест може бути невдалим. Це як Fullstory/LogRocket, але для збоїв CI замість виробничих помилок. (Ми починаємо з тестування Cypress і плануємо продовжити.)

Наш інструмент інтегрується з Cypress через їхній плагін API, тож ми можемо підключати та записувати тести в CI лише за допомогою встановлення NPM і 2 рядків коду. Звідти ми можемо підключатися до подій Cypress/Mocha, щоб фіксувати все, що відбувається в програмі тестування (наприклад, коли починається тест, коли запускається команда, коли знайдено елемент тощо), а також відкривати порт протоколу налагодження. з браузером для прослуховування подій мережі та консолі. Коли набір тестів запущено, налагоджувач систематично збирає те, що відбувається під час тестування, і завантажує інформацію (мінус будь-які налаштовані користувачем цензуровані події) після завершення кожного тесту.

Хоча це може здатися схожим на вставлення LogRocket/FullStory у ваш набір тестів, насправді є чимало відмінностей. Найбільш зручним є те, що ці інструменти зазвичай мають низьку пропускну здатність, яка добре працює для людського трафіку, що взаємодіє з веб-програмами на швидкості людини, але ламається, коли справа доходить до трафіку від паралелізованих тестувальників, які взаємодіють із веб-програмами на машинній швидкості. Інші незначні деталі пов’язані з тим, що ми пов’язуємо повтори з тестовими метаданими на відміну від метаданих користувача, маємо повний доступ до всіх мережевих запитів/повідомлень консолі, виданих під час тестування на рівні браузера, та індексуємо нашу прочитану інформацію на основі тестових команд, а не часових позначок (час ненадійна концепція в тестуванні!).

Один раз на п...

What's Your Reaction?

like

dislike

love

funny

angry

sad

wow