что такое тестирование end to end сквозное
Про пользу E2E тестирования
В пирамиде тестирования End-to-End (E2E) тесты занимают одну из верхних ступеней. Написав один E2E тест, можно быть уверенным в результатах работы логики приложения, проверить интеграции с другими системами и создать «контракт» для вашего приложения.
К сожалению, многие из коллег, с которыми я работал, не писали E2E тесты. Отчасти потому что с головой ушли в модульное тестирование и посчитали, что оно лучше по ряду причин, включая моду на TDD. Отчасти потому что верили, что E2E тесты сложно писать, они долго исполняются, да и с инструментарием есть проблемы.
Разберемся с этими мнениями и посмотрим на плюсы, которые предлагает E2E тестирование.
Терминология
Под E2E тестами положим вид автотестов. Эти автотесты должны покрывать все функции сервиса с точки зрения клиента. Добиваются они этого, симулируя реальное взаимодействие клиента, будь это HTTP-запрос или нажатие на кнопку в UI.
Подход модульного тестирования лучше
Написание модульных тестов, по моему опыту, занимает куда больше времени, чем E2E тестов. Да, на первых порах придется разобраться как E2E тесты лучше писать, но ведь то же было верно и для модульных тестов.
Зато, в результате один E2E тест покрывает больше кода, чем один Unit-тест, хотя может занимать меньшее количество строк по сравнению с аналогичным модульным test suite.
Можно не тратить время на понимание того, как правильно мокировать зависимости, ведь ими становятся в E2E тестах внешние системы, а взаимодействие с тестируемым сервисом строится по принципу «черного ящика».
Не нужно проверять все граничные условия для отдельного метода класса. Это повышает гибкость работы с кодом, так как нет необходимости рефакторить весь test suite при малейшем изменении внутренней логики работы приложения.
Невозможно попасть в ситуацию, когда ты боишься выкинуть старый код, потому что придется пройтись по набору из 100 модульных тестов (написанных даже не тобой), которые так или иначе были завязаны на этот код.
Инструментарий и скорость прогона тестов
На сегодняшний день большинство backend-разработчиков пишут сервисы, представляющие API с помощью HTTP (возможно GraphQL) или некоторым подобием MQ. В таком случае достаточно обычного клиента HTTP, доступного в большинстве mainstream ЯП.
Frontend-разработчики пишут, в основном, для Web-платформ (браузеров) или для мобильных в виде нативных приложений. Тут ситуация немного сложнее, так как инструментарий требует более детального изучения, но не дольше любого остального инструмента, с которым Вам придется столкнуться при разработке приложений.
E2E тесты действительно требуют в среднем больше времени для прогона, нежели модульные. При этом они завязаны на скорость работы Вашей системы. Т.е. они становятся метрикой производительности отдельных операций. При необходимости, они могут просто преобразовываться в нагрузочные тесты.
Дополнительные плюсы E2E тестирования
Каждый отдельный тест покрывает реальный сценарий использования приложения и дает куда больше понимания другим разработчикам, в том числе и будущим, как именно и зачем все это работает.
По результатам работы Вы получаете «настоящий» code-coverage. Если есть код и его невозможно исполнить, выполняя клиентские запросы в реальном окружении, то, скорее всего, это лишний код. Если он проверяет граничные условия или ловит маловероятный exception, задумайтесь, возможны ли такие условия в принципе?
В целом, использование только E2E тестирования для приложения заставляет задуматься об упрощении структуры Вашей системы и улучшения документации.
E2E тесты могут использоваться как контракты API и взаимодействия с Вашим сервисом. К примеру, для backend, как только Ваш E2E тест меняется, необходимо убедиться, что frontend будет готов к таким изменениям.
Заключение
В целом, на мой взгляд, E2E тестирование предоставляет большие гарантии корректной работы системы, чем unit-тесты, большую гибкость в работе с кодом с точки зрения рефакторинга и отражает реальную суть работы приложения.
Спасибо Вам за внимание! А как Вы считаете, можно ли использовать только E2E тесты?
Просто скажите «нет» end-2-end тестам
У вас наверняка было такое, когда вы и ваши друзья очень хотели посмотреть какой-нибудь фильм, а после жалели о том, что потратили на него время. Или, может быть, вы помните тот момент, когда ваша команда думала, что нашла «киллер фичу» и обнаруживала ее «подводные камни» только после выпуска продукта.
Хорошие идеи часто терпят неудачу на практике, и в мире тестирования хорошим примером этого может служить стратегия тестирования, построенная на автоматизации end-to-end тестов.
Тестировщики могут инвестировать свое время на написание многих типов автоматических тестов, включая модульные тесты, интеграционные тесты и end-2-end тесты, но эта стратегия в основном направлена на end-2-end тесты, которые проверяют продукт или услугу в целом. Как правило, эти тесты имитируют реальные пользовательские сценарии.
End-2-end тесты в теории
Хотя полагаться в первую очередь на end-2-end тесты — плохая идея, но теоретически можно придумать несколько доводов в пользу этого утверждения.
Итак, номер один в списке Google из десяти вещей, которые, как мы знаем, являются правдой: «Интересы пользователей превыше всего». Таким образом, использование end-2-end тестов, которые фокусируются на реальных пользовательских сценариях, выглядит отличной идеей. Кроме того, эта стратегия в целом привлекательна для многих участников процесса.
End-2-end тесты на практике
Итак, если эта стратегия тестирования выглядит так хорошо в теории, то что же с ней не так на практике? Чтобы продемонстрировать это, я ниже приведу выдуманный сценарий, но который основан на реальных ситуациях, знакомых как мне, так и другим тестировщикам.
Допустим команда создает сервис для редактирования документов в режиме онлайн (например, Google Docs). Давайте предположим, что у команды уже есть какая-то фантастическая инфраструктура для тестирования. Каждую ночь:
Несмотря на многочисленные проблемы, тесты в конечном итоге выявили реальные ошибки.
Ошибки, влияющие на пользователя, были выявлены и исправлены до того, как они к нему попали.
Истинная ценность тестов
Как правило, работа тестировщика заканчивается, когда тест провален. Ошибка регистрируется, и затем задача разработчика — исправить ошибку. Однако чтобы определить, где end-2-end стратегия не срабатывает, нам нужно выйти за рамки этого мышления и подойти к проблеме используя наши базовые принципы. Если мы «сосредоточимся на пользователе (а все остальное приложится)», мы должны спросить себя: приносит ли проваленный тест пользу пользователю?
Вот ответ: «Проваленный тест напрямую не приносит пользы пользователю».
Хотя это утверждение, на первый взгляд, кажется шокирующим, оно верно. Если продукт работает, он работает, независимо от того, говорит ли тест, что он работает или нет. Если продукт сломан, он сломан, независимо от того, говорит ли тест, что он сломан или нет. Итак, если проваленные тесты не приносят пользы пользователю, то что же приносит ему пользу?
Исправление ошибок напрямую приносит пользу пользователю.
Пользователь будет счастлив только тогда, когда это непредсказуемое поведение (ошибка) исчезнет. Очевидно, чтобы исправить ошибку, вы должны знать, что она существует. Чтобы узнать, что ошибка существует, в идеале у вас должен быть тест, который ее обнаруживает (потому что если тест не выявит ошибку, то ее найдет пользователь). Но во всем этом процессе, от провала теста до исправления ошибки, добавленная стоимость появляется на самом последнем шаге.
Таким образом, чтобы оценить любую стратегию тестирования, вы не можете просто оценить, как она находит ошибки. Вы также должны оценить, как это позволяет разработчикам исправлять (и даже предотвращать) их.
Построение правильной обратной связи
Тесты создают цикл обратной связи, который информирует разработчика о том, работает продукт или нет. Идеальный цикл обратной связи имеет несколько свойств.
Думайте о малом, а не о большем
Так как же нам создать этот идеальный цикл обратной связи? Думая о малом, а не о большем.
Модульное тестирование
Модульные тесты берут небольшой фрагмент продукта и тестируют его изолированно от всего остального. Они почти создают тот самый идеальный цикл обратной связи:
Модульные тесты против end-2-end тестов
При end-2-end тестах вам нужно подождать: сначала создания всего продукта, затем его развертывания и, наконец, выполнения всех end-2-end тестов. Когда тесты все же заработали, вероятнее всего, они периодически будут сбоить. И даже если тест обнаружит ошибку, она может быть в любом месте продукта.
Хотя сквозные тесты лучше справляются с моделированием реальных пользовательских сценариев, это преимущество быстро перевешивается всеми недостатками сквозного цикла обратной связи:
Интеграционные тесты
У модульных тестов есть один существенный недостаток: даже если модули работают хорошо по отдельности, вы не знаете, хорошо ли они работают вместе. Но даже тогда вам не обязательно проводить end-2-end тесты. Для этого вы можете использовать интеграционный тест. Интеграционный тест берет небольшую группу модулей, часто два, и тестирует их поведение как единого целого.
Если два блока не интегрируются должным образом, зачем писать сквозной тест, когда вы можете написать гораздо меньший, более сфокусированный интеграционный тест, который обнаруживает ту же ошибку? Конечно, вы должны понимать весь контекст при тестировании, но для того, чтобы проверить работу двух модулей вместе вам всего лишь нужно совсем чуть-чуть расширить перспективу.
Пирамида тестов
Даже при проведении и модульных, и интеграционных тестов вам, скорее всего, потребуется небольшое количество end-2-end тестов для проверки системы в целом. Чтобы найти правильный баланс между всеми тремя типами тестов, лучше всего использовать визуальную пирамиду тестирования. Вот упрощенная версия пирамиды тестирования из вступительной речи конференции Google Test Automation 2014 года.
Основная часть ваших тестов — это модульные тесты в нижней части пирамиды. По мере того как вы продвигаетесь вверх по пирамиде, ваши тесты становятся более всеобъемлющими, но в то же время количество тестов (ширина вашей пирамиды) уменьшается.
По-хорошему, Google предлагает разделение 70/20/10: 70% модульных тестов, 20% интеграционных тестов и 10% end-2-end тестов. Точное соотношение будет отличаться для каждой команды, но в целом она должна сохранять форму пирамиды. Старайтесь избегать следующих «форм»:
Что такое end-to-end тестирование?
Извиняюсь за глупый вопрос, но я не очень хорошо понимаю что значит end-to-end тестирование.
Если кого не затруднит помогите разобраться. Заранее спасибо.
Для понимания сути этого понятия хорошо сравнить его с модульным («нижний» уровень) и интеграционным («средний») тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных «модулей», если их собрать вместе согласно архитектурe. Например, работает ли правильно «Корзина», состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или «Корзина», подключенная к «Вебморде» и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа.
Это просто тест который проверяет что вся система работает в целом?
Сквозные тесты
Dec 8, 2019 · 7 min read
Несколько слов о сквозных тестах.
О чем статья
Статья в больше степени будет описывать сквозные тесты. Будет описан процесс, реализованный в последнем моем проекте. Также статья балы написана как предложение развития автоматизациия тестирования в компании, которой я работаю.
Для чего нужны e2e тесты
Сквозное, end-to-end — это тестирование системы в целом, эмулируя реальную пользовательскую среду. Это тесты, запущенные в браузере, имитирующие щелчки мышью и нажатия клавиш. Сквозным оно называется, потому что проверяют бизнес функции системы. Если брать терминологию тестирования, то e2e — это поведенческое тестирование по методу «чёрного ящика» (проверка выполнения приложением заданных функциональных требований, при которой не используются знания о внутренней структуре тестируемого объекта). То есть мы тестируем, что система работает, как планировалось, с точки зрения конечного пользователя.
Пользователю всё равно, работает ли приложение «как планировалось», ему важно, чтобы функционал работал в соответствии с его собственными ожиданиями. Тестирование по сути это автоматизированный запуск приложения в браузере и последовательные действия, проверяющие весь функционал пользовательского интерфейса. Совершать все эти действия вручную было бы крайне неэффективно, поэтому создадим автоматические тесты.
В итоге тесты нужны для следующих вещей:
Пирамида тестирования
Вспомним пирамиду тестирования, где показывается распределение по типам тестов в приложении.
На написание и запуск E2E-тестов требуется время и ресурсы. Google например предлагает разделение 70/20/10: 70% unit тестов, 20% интеграционных тестов и 10% E2E-тестов. Точная комбинация будет отличаться для каждого проекта, но в целом она должна сохранить форму пирамиды.
Из пирамиды, как мы знаем, следует что тестов необходимо писать малое количество, это объясняется следующими причинами:
1. Хорошо написанных интеграционных и юнит-тестов должно хватить. E2E-тесты должны проверить, что все элементы корректно связаны между собой.
2. Скорость выполнения. Если их будет сотни, как юнит-тестов и интеграционных, то тестирование будет проходить очень долго.
3. Непредсказуемость. Так как имитируется пользовательская среда, то в таймаут могут не проходить некоторые тесты из-за API браузера. С юнит(интеграционными) тестами такого быть не может.
Когда использовать e2e тесты
По хорошему, e2e-тесты стоит использовать в каждом проекте, в котором есть команда(dev, qa, pm). Но стоит отметить, что внедрять e2e тесты стоит использовать только когда покрыты unit тесты и интеграционные, только тогда будет понятно, что еще не покрыто в системе. Также необходимо учитывать возможность написания тестов, если проект короткий mvp, то нет смысла писать сквозные тесты, так как большая часть функционала может быть переписана и переделана.
Виды тестирования
Перед тем как говорить о сквозных тестах, стоит понимать к какому виду тестирования он относится и какое место он занимает. Классификация тестов обширная и всю ее мы приводить не будем.
Знание системы
Самым высоким уровнем в иерархии подходов к тестированию будет понятие типа, которое может охватывать сразу несколько смежных техник тестирования. То есть, одному типу тестирования может соответствовать несколько его видов. Рассмотрим, для начала несколько типов тестирования, которые отличаются знанием внутреннего устройства объекта тестирования.
По целям
Таким образом сквозные тесты являются функциональными тестами методом черного ящика. Стоит это учитывать при разработке теста.
Unit vs E2E
Между модульными тестами и сквозными много отличий и часто возникает вопрос какие тесты использовать. Ответ очевиден использовать и оба вида тестов в соответствии с пирамидой тестирования. Все же стоит уточнить разницу между этими видами.
Модульные тесты:
Сквозные тесты:
Концепции
Создание e2e начинается с описания пользовательской истории. Насколько тщательно мы подготовим описание на этом этапе, настолько просто будет команде разработчиков написать E2E-тест, который будет демонстрировать что все системы работают правильно при реализации этого сценария. Спустя какое-то время, технические писатели или новая команда разработчиков, вместо чтения документации, могут воспользоваться тестами, для того чтобы запустить и посмотреть реализованные сценарии в реальном браузере или автоматически записать видео-уроки.
Жизненный цикл сквозного теста следующий:
Как все устроено
Запуск тестов возможен двумя способами: через ci в автоматическом режиме, либо локально на машине разработчика. Сами тесты запускаются с помощью фреймворка, который в совокупности в веб-драйвером составляют движок автоматизации e2e, который может генерировать отчет о выполнении, также движок запускает браузер и взаимодействует с ним(отправляет команды, запускает тесты), браузер в свою очередь запускает тестируемое приложение, которое взаимодействует в бекендом. Бекенд в стандартной манере взаимодействует в БД, в этом плане ничего не меняется, связка приложения и бекенда с БД, остается неизменным. Также движок автоматизации должен хранить в актуальном состоянии БД перед запуском каждого теста.
Protractor
Protractor — это программа Node.js, построенная поверх WebDriverJS. Protractor работает как интегратор решений, объединяющий мощные технологии, такие как Node.js, Jasmine, Selenium, Mocha, Cucumber и Web.
Каждый тест представляет собой два файла для теста страницы (spec и po). Ниже представлен код проверяющий заголовок на конкретный текст.
Каждая страница оборачивается в тестовую группу describe и каждый тест-кейс обозначается через it — синтаксис аналогичен Jasmine. Каждый элемент страницы ищется через встроенные в фреймворк методы. Все методы асинхронные, это стоит учитывать при разработке, чтобы тесты выполнялись стабильно.
Весь повторяющийся код переводится в beforeEach, если код специфичный для конкретных тестов, то он выносится в page Object. Так как protractor использует Selenium, то по умолчанию используется паттерн Page Object.
Page Object Pattern
Page Object активно используется при разработке тестов и стоит понимать почему именно этот шаблон проектирования используется в protractor. Page Object это шаблон проектирования, который широко используется в автоматизированном тестировании и позволяет разделять логику выполнения тестов от их реализации.
Style guide
Стайл гайд взят из https://www.protractortest.org/#/style-guide. В статье указаны правила, которые используются в наших проектах.
Автоматизация на проектах
1. Выбрать фреймворк для тестирования. В нашем случае мы выбрали protractor, так как он по умолчанию встроен в Angular, но также можно выбрать другой фреймворк, но мы пошли по меньшему сопротивлению. В других средах, необходимо выбирать фреймворк для тестирования.
2. Выбрать основные тесты. Так как мы определились что мы не можем использовать много e2e тестов из-за их дороговизны в разработке и скорости выполнения, поэтому необходимо выбрать костяк основной функциональности системы, которая должна обязательно выполняться.
3. Интеграция CI/CD. Этот шаг очень важен, так как тесты обязательно должны запускаться автоматически и не должны попадать ан стенд не оттестированные разработчиком. Этот пункт касается не только e2e тестов но и всей кодовой базы.
Сквозные тесты внедрены в пайплайн сборки, но могут валится(решается внедрением докера). Составлены предложения по развитию автоматизации тестирования. Кроме того необходимо больше проектов, где возможно внедрить сквозные автотесты. Но стоит отметить, что перед внедрением тестов стоит учитывать, что нужны устаканенные ТЗ и тест-кейсы с пользовательскими сценариями.
Как проводить сквозное (end-to-end) тестирование вашего приложения используя Cypress.io
В этой статье вы узнаете:
Что такое Cypress и когда его стоит использовать
Основы тестирования с использованием Cypress
Расширенные команды Cypress
Взаимодействие с элементами пользовательского интерфейса
Лучшие практики с использованием Cypress
Введение
Чтобы протестировать свои приложения, вам потребуется сделать следующие шаги:
Подождать пока сервер запустится
Провести ручное тестирование приложения(нажать на кнопки, ввести случайные текст в поля ввода или отправить форму)
Проверить, что результат вашего теста корректен(изменения заголовка, части текста и т.д.)
Повторить эти шаги ещё раз после простых изменений кода
Повторение этих шагов снова и снова становится утомительным и отнимает у вас слишком много времени и энергии. Что, если бы мы могли автоматизировать этот процесс тестирования Благодаря этому вы можете сосредоточиться на более важных вещах и не тратить время на тестирование пользовательского интерфейса снова и снова.
Именно здесь в игру вступает Cypress. При использовании Cypress единственное, что вам нужно сделать, это:
Написать код вашего теста(нажатие на кнопку, ввод текста в поля ввода и т.п.)
Запустить или перезапустить тест
Только и всего! Библиотека Cypress выполняет все тесты за вас. И самое приятное, что она не только сообщает вам все ли ваши тесты успешны или нет, но также сообщает вам, какой тест не удался.
Помимо этого, тестирование вашего кода — отличная практика, поэтому вам придется позже изучить соответствующий фреймворк. Cypress позволяет запускать тесты за считанные минуты.
Теперь, когда мы обсудили преимущества Cypress, давайте узнаем об основах этой библиотеки.
Начало
Установка и настройка Cypress
Сначала создайте отдельную папку для вашего проекта, а затем инициализируйте ее:
Инициализация проекта
Наконец, чтобы установить библиотеку Cypress:
Установка Cypress
Теперь, когда Cypress установлен, попробуйте запустить его с помощью следующей команды:
Открытие Cypress
Она открывает запускалку тестов(Test Runner):
Интерфейс Test Runner
А теперь давайте перейдём к написанию тестов.
Основы Cypress
Создание файла
Переход к cypress/integration
Теперь создайте файл JavaScript с именем basicTest.js :
Создание JavaScript файла
Если вы не отключили сервер Cypress, ваши новые файлы появятся в Test Runner в реальном времени:
Обновление структуры файлов в реальном времени
Теперь давайте напишем наш первый тест.
Простые тесты с утверждением и ожиданием значения
В вашем файле /cypress/integration/basicTest.js напишите следующий код:
Код к файлу basicTest.js
Строка 1: Функция describe сообщает Cypress название набора наших тестов.
Чтобы запустить вашу программу, щёлкните по basicTest.js в вашем сервере Cypress.
Щелчок по basicTest.js в Test Runner
Результат запуска теста
Отлично! Значит, наше утверждение было успешным.
Что, если мы сделаем заведомо ложное утверждение? Теперь в /cypress/integration/basicTest.js добавьте следующий код в пределах функции describe :
Код для добавление в basicTest.js
Строка 2: Если сумма 4 и 5 равна 10, тест будет пройден. В противном случае, незамедлительно остановлен.
Снова запустите код. Результат будет:
Результат нашего второго теста
Обратите внимание, как наш второй тест не удался. Если бы результат был правильным, тест прошел бы успешно.
Давайте больше поиграем с утверждениями. Добавьте в basicTest.js следующий код:
Код для добавления в basicTest.js
Строка 2: Если сумма 5 и 5 не равна 100, то тест должен пройти.
Результат выполнения теста:
Результат теста: успешно!
Отлично! Наш тест прошел. Функция expect выполняет BDD (behavior-driven) утверждения. В следующем разделе мы выполним утверждения, основанные на тестировании(test-driven assertions).
Сейчас /cypress/integration/basicTest.js должен выглядеть так:
Написание утверждений основанных на тестировании(test-driven assertions) с явным использованием assert
В вашем файле basicTest.js напишите следующий код:
Строка 10: Убеждаемся, что переменная name содержит строковое значение.
Строка 14: Убеждаемся, что переменная name не является целым числом.
Запустите код. Результатом будет:
Результат запуска нашего теста
Отлично! Наш код работает. В следующем разделе мы научимся работать с сайтами через Cypress.
Сейчас наш basicTest.js должен выглядеть так:
Запуск веб-сайтов
Код для basicCommandsTest.js
Сохраните свой код и нажмите на basicCommandsTest.js в меню Test Runner:
Клик по basicCommandsTest.js вTest Runner
Отлично! Наш код работает. В следующем разделе мы более глубоко погрузимся в тестирование с помощью Cypress.
В итоге basicCommandsTest.js должен выглядеть так:
Cypress: Расширенные команды
В этом разделе мы попытаемся взаимодействовать с элементами на странице. Однако, прежде чем продолжить этот процесс, нам нужно сначала научиться идентифицировать элементы HTML в Cypress.
Как идентифицировать элементы
Cypress использует селекторы JQuery для идентификации компонентов на веб-странице.
Получение элемента через id элемента
В качестве альтернативы, чтобы идентифицировать элемент myButton используя имя класса, могли бы использовать следующую строку:
Получение элемента через имя класса
Давайте теперь поработаем с взаимодействием с пользовательским интерфейсом нашего сайта.
Нажатие кнопки
В этом разделе мы будем использовать страницу The-Internet для запуска наших тестов. На этом веб-сайте мы будем использовать раздел добавления/удаления элементов.
Давайте сначала попробуем идентифицировать нашу кнопку «Добавить элемент».
Страница для тестирования
Скриншот из DeveloperTools
Соответствующий селектор для этой кнопки будет выглядеть так:
Идентификация элемента
Строка 2: Переходим на веб-страницу.
Строка 6: Связываем в одну цепочку получение элемента button и нажатие на эту кнопку.
Запустите код. Результат:
Вывод результата
Давайте теперь поработаем с вводом текста в текстовое поле.
Ввод текста
В этом разделе мы будем использовать страницу The-Internet’s login. Нам нужен способ сначала идентифицировать элементы.
Скриншот сайта для тестирования Скриншот из DeveloperTools Скриншот из DeveloperTools
Идентификация элемента через его id
Строка 3: Переходим на страницу входа в систему.
Строка 10: Нажимаем на кнопку «Отправить».
Запустите код. Результатом будет:
Вывод результата запуска кода
И мы закончили! В следующем разделе мы узнаем о работе с чекбоксами.
Переключение чекбоксов
Давайте сначала посмотрим на DevTools:
Developer Tools
Идентификация наших чекбоксов
В каталоге /cypress/integration/ создайте файл с именем runningCheckCommand.js и напишите следующий код:
Строка 7: Просим Cypress приостановить процесс тестирования на одну секунду.
Запустите код. Результат:
Результат запуска теста
Отлично! Наш код работает. Давайте теперь поработаем над неявными утверждениями с помощью Cypress.
Неявные утверждения
Ранее мы выполняли утверждения для переменных и объектов. Однако в реальном мире мы хотели бы выполнять утверждения для текста, расположенного в нашем элементе HTML, или проверять, есть ли у нашего элемента ul дочерние элементы li или нет.
Скриншот тестируемой страницы Developer Tools
Наше утверждение
Для этого мы должны использовать следующий синтаксис:
Получение элемента и за тем утверждение
Альтернативно, можем выполнить такое утверждение:
Наше утверждение
Мы можем использовать эту строку кода:
Получение элемента и затем утверждение
Перейдите в /cypress/integration/runningClickCommand.js и добавьте следующий код:
Код для runningClickCommand.js
Запустите код. Результат в конце теста должен быть следующим:
Результат запуска
В итоге cypress/integration/runningClickCommand.js должен выглядеть так:
Команда each
Скриншот тестового сайта
Откройте Developer Tools:
Получение элемента и использование each затем
Перейдите в /cypress/integration/runningClickCommand.js и добавьте следующий фрагмент кода:
Код для runningClickCommand.js
Строка 3: Обёртываем этот элемент, чтобы мы могли выполнять с ним команды Cypress. Здесь мы отправляем команду щёлкнуть по этим элементам.
Результат выполнения кода должен быть следующим:
Результат выполнения кода
Наш код работает! Поскольку наш тест был быстрым, давайте попробуем добавить на страницу больше элементов.
Найдите следующий фрагмент кода:
Строка 2: Запускаем цикл, чтобы сообщить Cypress, что нужно нажать кнопку Add Element 20 раз.
Запустите код еще раз. Результат должен быть таким:
Результат выполнения кода
Как видите, наша программа автоматически удалила все элементы на странице без каких-либо ручных усилий. Отлично!
В следующей части статьи мы узнаем о том, что можно и чего нельзя делать при тестировании с Cypress.
В итоге cypress/integration/runningClickCommand.js должен выглядеть так:
Лучшие практики
Держите тесты изолированными
Рассмотрим ситуацию, когда вы тестируете свое приложение. Структура вашего проекта будет выглядеть примерно так:
Не самая лучшая структура
В вашем Test Runner это будет выглядеть так:
Отображение тестовой структуры в Test Runner
Команда Cypress утверждает, что структура вашего проекта должна быть организована как можно лучше. Лучше всего перегруппировать ваши файлы проекта в другие папки, например:
Хорошая структура проекта
Следовательно, это выглядело бы так:
По возможности используйте собственные команды
Взгляните на этот фрагмент кода:
Пример кода
В вашем cypress/support/commands.js напишите этот код:
Строка 2: Получаем элемент с соответствующим идентификатором, а затем вводим в него данные.
Теперь вернитесь в свой тестовый файл и замените его вот так:
Пример кода
Как видите, наш код выглядит значительно короче.
Избегайте «атомарных» тестов
Взгляните на этот фрагмент кода:
Cypress не одобряет такого поведения. Это неэффективно, и есть способ лучше переписать этот код, например:
Мы можем использовать метод and для связывания дополнительных команд should с нашим элементом.
Не запускайте сервер в Cypress
Команда exec присутствует для запуска команд в терминале. Но запускать сервер с помощью этой команды крайне не рекомендуется.
Команды терминала
Репозиторий GitHub и дополнительные ресурсы
Код GitHub
Дальнейшее чтение
Заключение
Тестирование — ключевой шаг в процессе разработки, поскольку он обеспечивает правильную работу вашего приложения. Некоторые программисты предпочитают вручную тестировать свои программы, поскольку написание тестов требует значительного количества времени и энергии. К счастью, Cypress решил эту проблему, позволив разработчику писать тесты в короткие сроки.
Спасибо, что дожили до конца! Если вы почувствовали какое-либо замешательство, я советую вам поиграть с кодом и разобрать примеры.