Как наша команда реализовала сквозное тестирование за 4 простых шага
В Hubba потребности нашего бизнеса постоянно развиваются, и скорость развития должна их догонять. Один из способов заставить команду двигаться вперед, не ломая ничего, - это сквозное (E2E) тестирование.
Наличие полного набора тестов с тестами E2E позволяет нам действовать быстро. Он позволяет разработчикам продвигать код, не беспокоясь о поломке. Он позволяет выпускать выпуски с особой уверенностью. И это выявляет ошибки, пропущенные во время ручного регрессионного тестирования.
Что такое E2E-тестирование?
Сквозное тестирование - это когда вы тестируете все свое приложение от начала до конца. Это включает в себя обеспечение того, чтобы все интегрированные части приложения функционировали и работали вместе, как ожидалось.
Сквозные тесты моделируют реальные пользовательские сценарии, по сути, проверяя, как реальный пользователь будет использовать приложение.
Примером для Hubba может служить тестовый пример E2E для регистрации пользователя.
Тест будет включать:
- открытие Hubba в браузере и поиск определенных элементов
- выполнение набора щелчков и типов клавиатуры
- обеспечение успешного создания пользователя
Почему вас это должно волновать?
В Hubba мы твердо верим в автоматизацию тестирования. В настоящее время мы пишем модульные и интеграционные тесты для нашего кода.
Эти тесты используются для:
- укажите нашу систему
- предотвратить ошибки и регресс
- выполнять непрерывную интеграцию
Кроме того, эти тесты запускаются как можно чаще, чтобы обеспечить обратную связь и убедиться, что наша система остается чистой.
Мотивация для дополнительного уровня тестов E2E заключается в преимуществах наличия полностью автоматизированного набора тестов. Эти преимущества включают увеличение скорости разработки, а также другие ранее упомянутые преимущества.
E2E-тесты позволяют нам охватить те разделы приложения, которые не охватываются модульными и интеграционными тестами. Это связано с тем, что модульные и интеграционные тесты берут только небольшую часть приложения и оценивают ее изолированно.
Даже если эти части хорошо работают сами по себе, вы не обязательно знаете, будут ли они работать вместе как единое целое. Наличие набора сквозных тестов поверх модульных и интеграционных тестов позволяет нам тестировать все наше приложение.
Чем быстрее код выходит из строя, тем меньше ошибок мы находим в QA, тем быстрее проходят наши циклы QA - Эдвард Робинсон
Это пирамида тестирования из блога Кента С. Додда, которая представляет собой комбинацию пирамид из блога Мартина Фаулера и блога тестирования Google.
Большинство ваших тестов находятся в нижней части пирамиды. По мере продвижения вверх по пирамиде количество тестов становится меньше. Поднимаясь по пирамиде, тесты становятся медленнее и дороже в написании, запуске и обслуживании.
Мы хотим написать очень небольшое количество сквозных тестов из-за того, что они работают медленно и, как ожидается, будут меняться. Это особенно важно, потому что как стартап мы хотим двигаться быстро.
Google часто предлагает разделение 70/20/10: 70% модульных тестов, 20% интеграционных тестов и 10% сквозных тестов. Точный состав будет отличаться для каждой команды, но в целом он должен сохранять форму пирамиды. - Блог тестирования Google
4 шага к началу работы
1. Выберите платформу тестирования.
Первое, что мы предприняли для начала, - это оценка различных сред тестирования E2E. Наша оценка не включает рассмотрение всех функций фреймворка, а скорее общее впечатление. Основным критерием было выбрать фреймворк, который будет легко настроить и быстро начать работу.
Мы быстро просмотрели следующие фреймворки: CasperJS, Protractor, Nightwatch и Testcafe.
Мы приняли решение использовать TestCafe из-за простой установки и запуска. Он довольно новый, но становится все более популярным. Примечательно, что его легко настроить, потому что он не требует WebDriver.
Поскольку WebDriver не требовался, не было необходимости устанавливать и поддерживать дополнительные продукты и плагины для браузера. Тесты можно запускать сразу после установки npm. Это позволило нам быстро написать доказательство концепции / прототипа, которое поможет нам начать работу.
TestCafe использует async / await и код ES2017 для файлов тестов. Он также имеет неявный механизм автоматического ожидания, который означает, что TestCafe автоматически ожидает запросов XHR и загрузки страниц. Так что вам не нужно заботиться об этом в своем коде.
- Pure Node.js - TestCafe построен на основе Node.js и не использует Selenium и не требует дополнительных модулей для запуска тестов в реальных браузерах. Он интегрируется и отлично работает с современными инструментами разработки.
- Никакой дополнительной настройки или конфигурации - TestCafe готов к запуску тестов сразу после
npm install. - Полный набор средств тестирования - с помощью одной команды запуска TestCafe запускает браузеры, запускает тесты, собирает результаты и создает отчеты.
2. Выберите важные тесты.
Вторым шагом было определение основных тестовых примеров, которые мы напишем для нашего приложения.
Одна из наших проблем связана с регрессионным тестированием QA. Наш цикл обеспечения качества (QA) состоит из ручного тестирования, которое включает в себя регрессионный тест в конце.
Эти регрессионные тесты - это ручной процесс, который занимает много времени и потенциально может пропустить что-то из-за человеческой ошибки.
Мы решили написать тестовые примеры, связанные с этими регрессионными тестами. Для Hubba это включало базовые, но важные функции, такие как регистрация / вход пользователя и создание продукта.
Первоначальная партия тестовых случаев:
- Регистрация бренда / покупателя / влиятельного лица
- Авторизоваться
- Создать продукт
3. Интеграция в конвейер CI / CD.
Следующим шагом была интеграция этого в конвейер непрерывной интеграции и непрерывного развертывания или CI / CD. Цель добавления тестов E2E в наш конвейер - выявить любые ошибки или неудачные тесты до того, как код будет отправлен в производство.
Мы подумали о двух разных способах интеграции этого в нашу систему.
- Запуск тестов каждый раз, когда в проект добавляется новый код.
- Периодический запуск тестов.
Мы решили проводить наши тесты E2E периодически, еженедельно / еженедельно, а не выполнять тесты при каждом изменении кода как части конвейера CD. Причина этого в том, что тесты E2E выполняются медленно.
Мы не хотим, чтобы эти тесты замедляли наш конвейер, поскольку они задерживают наш процесс и цикл и влияют на запросы на вытягивание, слияние и развертывание в различных средах.
Нам нужен набор основных тестов E2E, которые мы можем запускать на регулярной основе, чтобы мы знали, что что-то не работает или сломано. Вот почему мы решили проводить эти тесты каждую ночь с помощью cron job Jenkins.
4. Создайте подтверждение концепции / прототип
Последним шагом было создать доказательство концепции или прототипа, чтобы продемонстрировать выполнение тестов E2E, а затем включить их в нашу систему.
Нам также пришлось решить либо полностью интегрировать тесты E2E в нашу текущую кодовую базу, либо создать разовый проект, отдельный от основной кодовой базы.
Для первоначального прототипа мы выбрали новый репозиторий, изолированный от нашей основной кодовой базы, и запустили наши тесты в промежуточной среде.
В заключение, хотя тестирование E2E очень дорогое в обслуживании, мы считаем, что они очень ценны, поскольку являются отличным аналогом поведения пользователя, который помогает нам тестировать базовые функциональные возможности пользователя на Hubba.
