Почему не стоит использовать Cypress для тестирования компонентов?

Автор Кайлаш Балачандран
Первоначально опубликовано 20 декабря 2021 года

Компания Storybook недавно объявила, что работает над функцией тестирования взаимодействия.

Учитывая рост библиотек на основе компонентов (Vue, React) и фреймворков, построенных на их основе (Nuxt, Next и т.д.), очень важно проводить конечное тестирование компонентов в изоляции. Компания Cypress объявила о выпуске альфа-версии своего специального инструмента Component Test Runner в версии 7.0. Он позволяет запускать тесты в браузере так же, как это делает посетитель вашего приложения. Эти тесты могут располагаться рядом с файлом компонента, где целью является создание тестов, ориентированных на каждый компонент, а не на все приложение. Такие тесты менее зыбки, могут выполняться гораздо быстрее и с меньшими накладными расходами, поскольку компонентные тесты не требуют маршрутизации страницы или загрузки остальной части приложения.

Однако я считаю, что если компонентные тесты Cypress способствуют разработке модульных и тестируемых компонентов, то в отношении документации пользовательского интерфейса он, конечно, упускает из виду. Если вы хотите создать документацию пользовательского интерфейса и руководство по стилю для компонентов, вам все еще придется полагаться на такие инструменты, как Storybook. (Если вы не знакомы с этим инструментом, вы можете ознакомиться с моей статьей, чтобы получить вводную информацию. Краткая версия: Storybook позволяет создавать части веб-приложения изолированно, с гораздо меньшими накладными расходами).

В случае с простым компонентом, например, кнопкой, это становится проблемой сопровождения, поскольку в итоге может получиться три/четыре файла для разных случаев использования, как показано ниже.

  1. Button.js (компонент)
  2. Button.unit.js (для модульных тестов)
  3. Button.storybook.js (документация пользовательского интерфейса)
  4. Button.cypress.js (тесты компонента Cypress).

Итак, вместо того, чтобы тестировать каждый отдельный компонент с помощью компонентного тест-раннера, почему бы нам не использовать e2e-test Storybook с помощью Cypress? Таким образом, мы получим лучшее из двух миров, т.е. красивую документацию пользовательского интерфейса, а также хорошо протестированное руководство по стилю компонентов.

Зачем тестировать Storybook

Прежде чем мы рассмотрим стратегии тестирования Storybook, давайте обсудим, почему тестирование Storybook важно. Я большой поклонник Storybook. Но, как и любое программное обеспечение, он подвержен гниению, если его не тестировать. Хотя он использует код совместно с вашим веб-приложением, он имеет отдельную конфигурацию, процесс сборки и пути кода. Это позволяет легко пропустить его тестирование. Одна из причин заключается в том, что разработчики склонны уделять больше внимания модульным и e2e-тестам, оставляя компоненты Storybook без тестирования.

Если в вашем проекте используется Storybook, очень важно задать эти вопросы:

  1. Если сборка Storybook окажется неудачной, как это будет обнаружено?
  2. Как вы будете уведомлены, если ваши компоненты Storybook не смогут отрисоваться?

Короткий ответ на №1 прост. То есть, CI должен давать сбои. Если ваше приложение не выполняет сборку Storybook в CI, крайне важно добавить ее в конвейер. Что касается #2, то ответ заключается в использовании e2e тестирования с помощью Cypress. Кроме того, в Storybook появится функция интеграционного тестирования, которая, по-видимому, станет жизнеспособной альтернативой компонентному тестированию. В следующих разделах мы кратко обсудим эти подходы.

Тестирование Storybook с помощью Cypress

Storybook — это, по сути, отдельное приложение с собственной конфигурацией сборки. На практике она может дать сбой, пока мы работаем над приложением, обновляем зависимости и так далее. Давайте напишем простой тест, который определяет, когда сборка Storybuild не работает, по крайней мере, в самых основных, легко обнаруживаемых случаях (например, когда история по умолчанию не может отрисоваться).

Я буду считать, что вы уже тестируете свое приложение с помощью Cypress. Для начала создайте вторую конфигурацию Cypress (cypress.storybook.json), которая будет указывать на URL вашего сервера Storybook (:9000 в примере ниже) и ссылаться на отдельную папку integration, чтобы разделить проблемы между чистыми e2e и storybook тестами.

//cypress.storybook.json
{
  "baseUrl": "http://localhost:9000",
  "integrationFolder": "cypress/storybook",
  ...
}
Вход в полноэкранный режим Выход из полноэкранного режима

Добавьте скрипты в package.json для удобства.

//package.json 
"scripts": {
    "start:storybook": "start-storybook -p 9000 -s public",
    "cy:test:storybook": "cypress run --headless -C cypress.storybook.json",
    ...
 }
Вход в полноэкранный режим Выход из полноэкранного режима

Теперь создайте файл storybook.spec.js в папке integration, как указано в файле button.storybook.json, и добавьте следующее.

// button.spec.js
const getIframeBody = () => {
   // get the iframe > document > body
   return cy
       .get('iframe[id="storybook-preview-iframe"]')
       // and retry until the body element is not empty
       .its('0.contentDocument.body').should('not.be.empty')
       // wraps "body" DOM element
       // https://on.cypress.io/wrap
       .then(cy.wrap);
}

describe("Button", () => {
   before(() => {
       cy.visit("/");
   });
   it("loads primary button with default text", () => {
       getIframeBody().get('#root').contains('button', 'Button');
   });
});
Вход в полноэкранный режим Выйти из полноэкранного режима

Как вы могли заметить, тест использует iframe. Работа с iframes немного сложна в Cypress. Потому что когда команды DOM Cypress достигают узла #document внутри iframe, операция обхода останавливается. Однако, как описано здесь, можно создать собственный код, чтобы заставить его работать. Приведенное выше решение является минимальным в смысле того, что оно делает. Но оно обеспечивает опору, если в будущем мы захотим добавить дополнительные тесты Cypress Storybook. Логику можно также расширить, чтобы даже манипулировать ручками и прочим через параметры запроса или использовать библиотеку cypress-storybook для добавления команд Cypress для Storybook. Библиотека напрямую вызывает маршрутизатор Storybook и предлагает команды для тестирования ручек компонентов, этикеток и т.д.

Тестирование взаимодействия Storybook

Storybook недавно объявила о том, что работает над функцией тестирования взаимодействия, которая позволит вам создавать сценарии взаимодействия и проверять ожидания в самой истории. Это позволит вам проводить функциональные тесты пользовательских интерфейсов в той же среде браузера, в которой вы их разрабатываете. Работающая на базе библиотеки Testing Library, она включает в себя возможности перемещения во времени, а также пермалинки для упрощения отладки. Имея встроенную тестовую установку, мы можем писать тесты взаимодействия внутри самой истории. Это также устанавливает четкую границу между Cypress и Storybook, где первый может сосредоточиться на чистых e2e тестах, а второй — на документации и тестировании компонентов.

Команды Cypress и Storybook работают над расширением поверхности своих инструментов, которые, похоже, сейчас пересекаются; Storybook с их Storybook Interaction Testing, Cypress с их Component Test Runners. Как уже говорилось, тестирование взаимодействия Storybook находится в стадии активной разработки. После его выпуска, я считаю, что это будет наилучший способ тестирования изолированных компонентов. Если ваше приложение еще не использует Storybook, самое время внедрить этот инструмент, поскольку он упрощает разработку пользовательского интерфейса и документации. Если в вашем приложении используется Storybook, написание тестов Storybook Cypress пока представляется приемлемым вариантом. Что касается компонентных тестов Cypress, я бы, конечно, не стал использовать их для компонентов, которые уже имеют документацию пользовательского интерфейса в Storybook. Я не говорю, что вы вообще не должны использовать Cypress Component Tests, но если у вас есть документация пользовательского интерфейса или вы строите систему проектирования, лучше запускать тесты взаимодействия Storybook в уже изолированной среде.

Отказ от ответственности: На момент написания этого блога Cypress Component Test Runner является альфа-версией, а тестирование взаимодействия Storybook находится в стадии активной разработки. Возможно, что с последующими релизами случаи, обсуждаемые в этом блоге, могут оказаться неправдой.

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *