3 шага, чтобы присоединиться к E2E
Поздравляем. Настройка end-to-end (E2E) — довольно сложная тема, и она может принести большую пользу вашему проекту. У него есть шанс отловить потенциальные проблемы до того, как изменения будут слиты с основной веткой — задолго до того, как он приблизится к развертыванию в рабочей среде. Чем раньше вы обнаружите ошибку, тем легче ее исправить. E2E позволяет проводить всестороннее тестирование, как только изменения становятся доступными.
Что такое сквозные тесты?
E2E-тесты — это сценарии, которые взаимодействуют с приложением так же, как и пользователь. Они открывают браузер, загружают URL-адрес, нажимают на элементы пользовательского интерфейса (UI), такие как кнопки, и ожидают каких-то результатов. Их выполняют машины, и они намного быстрее и надежнее, чем люди. Им никогда не бывает скучно.
Единственный недостаток — им нужны точные инструкции, и иногда их программирование может быть сложнее, чем функция, которую они пытаются протестировать. Написание тестов — это программирование, и оно связано с тестируемым приложением, но это задача, которая не особенно волнует многих программистов. Если вы преуспеете в этом, это может стать вашим уникальным навыком, который поможет вам блистать на работе.
Выбери свой инструмент!
Существует множество вариантов создания пакета E2E:
Здесь все так же, как и с другими решениями из технического стека: хорошо изучить свои варианты. Каждый тест, который вы пишете, тесно связан с выбранной вами платформой. Можно перейти с одного инструмента тестирования на другой, но это будет такой же большой проект, как замена интерфейсной среды.
Мой опыт в основном связан с Protractor, устаревшим решением, ориентированным на Angular. В настоящее время я переношу тесты на Cypress и впечатлен прогрессом инструментов тестирования за эти годы. Какой инструмент E2E вы хотели бы использовать в своем следующем проекте? Дайте мне знать в опросе.
Простые тесты на локальной машине
Делайте первые тесты тривиальными. Используйте любой имеющийся у вас локальный тестовый URL-адрес и просто обращайтесь к нему с помощью своих скриптов. Вам даже не нужно проверять рабочий процесс приложения. Просто напишите несколько тестов, каждый для разных маршрутов, и убедитесь, что элементы пользовательского интерфейса отображаются на странице. Например, вы можете проверить:
- на
/login, есть ли поля ввода логина и пароля - на
/product/12, отображается ли название продукта - и т. д.
Даже с помощью таких простых тестов вы можете доказать:
- что приложение запускается и все маршруты отображаются с ключевыми элементами пользовательского интерфейса
- что вы можете разрабатывать тесты E2E
И с этим E2E набирает обороты — у команды есть несколько тестов, и участник (вы) хочет и может написать больше тестов!
Пригласите свою команду на борт
Вам, вероятно, не нужно будет настойчиво говорить об этом поначалу. Просто убедитесь, что все знают о доступных тестах E2E, и сформируйте ожидание, что каждый разработчик должен запускать их перед слиянием в основную ветку. На этом этапе вы заметите все различия между локальными настройками ваших коллег — разные домены или порты, которые люди используют локально. Вы можете исправить это, либо заставив всех использовать один и тот же URL-адрес, либо сделав тестовый URL-адрес легко настраиваемым, а не жестко запрограммированным. Оба подхода в порядке. Я просто заставил всех использовать один и тот же URL-адрес локального хоста; в моем случае почти не было сопротивления со стороны команды.
Следующим шагом является проверка счастливого пути рабочего процесса — что должно делать приложение, когда все работает должным образом. Вы пишете тесты, которые проверяют, действительно ли кнопка «добавить в корзину» добавляет товары в корзину, и что «оформить заказ» переходит на страницу поставщика платежных услуг. Эти тесты сложнее написать, но они проверяют критически важные части приложения. Они должны помочь убедить ваших коллег в полезности E2E. И ваши тесты становятся немного более изощренными.
Если у вас есть какие-либо вопросы или сомнения по поводу E2E, не стесняйтесь, дайте мне знать! Вы также можете прочитать об управлении хрупким унаследованным кодом в моем блоге.
Первоначально опубликовано на https://how-to.dev.
