Как разработчики, мы программируем компьютеры на выполнение повторяющихся задач, чтобы людям не приходилось это делать. Проверка работоспособности потоков приложения после его обновления - классический пример повторяющейся задачи, которую следует автоматизировать. Однако плохие инструменты исторически делали написание и обслуживание этих сквозных тестов крайне неэффективными до такой степени, что многие команды не занимались автоматизацией. Начав новый проект с упором на автоматизацию, я потратил некоторое (часто разочаровывающее) время на оценку популярных инструментов тестирования E2E - Транспортир, TestCafe, Cypress и Puppeteer.
Требования
- Тесты E2E должны быть максимально реалистичными, поэтому тесты должны выдавать простые инструкции, которые напрямую соответствуют действиям пользователя в браузере, и исполнитель тестов должен точно следовать этим инструкциям.
- Тесты должны выполняться как часть автоматизированного процесса сборки в среде, максимально приближенной к локальной среде.
- Обработка асинхронности должна быть надежной и понятной.
На обслуживание этих тестов уходит много времени, а изменчивость между браузерами сейчас ниже, чем в прошлом, поэтому мне удобно запускать тесты только в Chrome.
Методология
Я написал набор тестов для каждого из инструментов, охватывающих:
- Вход в систему
- Сброс окружающей среды
- Тестирование счастливого пути нормального пользователя
- Тестирование счастливого пути администратора
И добавил этот пакет в конвейер сборки Gitlab.
Транспортир
Я много использовал Транспортир и обнаружил, что он отлично работает для основных сценариев, но становится нестабильным из-за сложности:
- Я обнаружил, что функция Protractor ждет Angular связывает тесты с тем, что происходит за кулисами, что в корне не соответствует пункту 1 выше и для меня является классическим примером попытки излишне фантазировать и в конечном итоге ошибаться. Средство выполнения тестов делает вещи, особенно связанные с загрузкой страниц, которые не записаны в тестах.
- Самый популярный способ запустить тесты Protractor в облаке - использовать Sauce labs. Хотя лаборатория Sauce предоставляет отличные инструменты, после нескольких часов тестов отладки, которые прошли, когда я указал свой локальный экземпляр Protractor на рабочий сервер, но потерпел неудачу в лабораториях Sauce, я отказался от попыток заполнить пробелы.
- Protractor выполняет множество причудливых вещей с потоком управления, так что вы можете писать асинхронные тесты, которые выглядят как синхронные тесты. Это здорово, когда это работает, но очень сложно понять, когда что-то идет не так. Я знаю, что вы можете использовать явные обещания / async, но это противоречит примерам в руководстве по стилю.
Для меня Protractor терпит неудачу, так стараясь быть простым, что в реальных случаях он оказывается слишком сложным.
TestCafe
TestCafe имеет отличные инструменты и запускается со своего собственного сервера (например, noSelenium), что означает, что локальные тесты выполняются в среде, очень близкой к среде процесса сборки.
- TestCafe также ожидает завершения запросов и будет ждать, пока элемент станет видимым, прежде чем пытаться щелкнуть по нему (вместо того, чтобы терпеть неудачу, как это сделал бы Protractor). Есть функция «ролей» для сохранения состояния разных пользователей. Однако с обеими этими функциями я обнаружил, что выполнение было непредсказуемым, и во время выполнения теста были действия (например, перезагрузка страницы), которые не были записаны в тестах. То, как роли управляют локальным хранилищем, не работало в некоторых потоках, что потребовало много времени на отладку.
- TestCafe было относительно просто настроить на Gitlab, и выполнение соответствовало тому, что я видел локально. Возможность хранить видео и снимки экрана в виде артефактов Gitlab очень помогает при отладке.
- TestCafe использует цепочки обещаний для потока управления, и я обнаружил, что они легко читаются и надежны.
Кипарис
Cypress также является вариантом без селена с отличным инструментарием, ориентированным на разработчиков.
Проблема с Cypress заключалась в том, что его было сложно настроить на Gitlab, и он выдавал много ошибок в отношении межсайтовой безопасности, которых я не видел локально. Проведя небольшое исследование, я решил, что, несмотря на отличный опыт местных разработчиков, работа на Gitlab выглядит слишком сложной.
Кукловод
Puppeteer - это инструмент для управления Chrome, а не средство запуска тестов, но вы можете использовать любой обычный инструмент запуска тестов JS для управления им (в конечном итоге я использовал Jasmine, чтобы обеспечить согласованность с моими модульными тестами).
- По умолчанию Puppeteer не выполняет никакого ожидания или управления состоянием. Это означает, что для тестов требуется больше кода (с явным ожиданием наличия элементов), но выполнение - это способ, очень близкий к способу взаимодействия пользователя с приложением.
- Настроить Puppeteer на Gitlab было легко, а поведение очень близко к тому, как тесты запускаются локально. Я реализовал мониторинг, запустив Puppeteer в лямбда-выражении AWS по расписанию - эта возможность работать в разных средах без неприятных сюрпризов - большая победа.
- Самый популярный шаблон для Puppeteer, кажется, явно использует async / await. Опять же, это приводит к немного большему количеству кода, но это очень легко рассуждать и прозрачно.
Решение
Инструментарий для разработки JS / Typescript в настоящее время великолепен, и было неприятно видеть, что среды тестирования E2E настолько плохи - в основном потому, что они пытаются быть слишком простыми и в конечном итоге становятся слишком сложными. Кукловод - единственный из этих четырех, где я чувствовал, что тестовый бегун делал точно и только то, что было написано в тестах, и, следовательно, я мог отлаживать любые проблемы без необходимости спускаться на уровень абстракции, чтобы иметь дело с управлением потоком. , Угловое состояние, управление хранилищем и т. Д.
Я использую Puppeteer около месяца, и он неизменно работает надежно и стабильно.
