Прежде чем мы начнем тестировать какой-либо код с помощью библиотеки тестирования React, мы должны понять, что такое библиотека тестирования React и ее основная цель? Это поможет нам понять, как мы должны тестировать наш код.
Что такое библиотека тестирования React?
Его руководящий принцип:
Короче говоря, важно, чтобы мы, как разработчики, тестировали наши приложения, думая о наших пользователях. Это дает несколько преимуществ. Например, написание тестов с учетом поведения пользователя может помочь нам создать более семантический HTML-код. Это важно, поскольку делает наши страницы более доступными для людей с ограниченными возможностями.
Один из способов сделать это — использовать соответствующие теги HTML для различных типов структур содержимого. Например, вместо того, чтобы использовать тег p для заголовка и стилизовать его с помощью CSS, мы должны использовать теги с h1 по h6. Это не только упрощает тестирование заголовка с помощью таких инструментов, как React Testing Library, но также позволяет программам чтения с экрана точно читать заголовок для пользователей с ограниченными возможностями.
В общем, мы можем изменить тег role любого HTML, но лучше этого не делать. При написании семантического HTML-кода нам не нужно менять теги ролей. Следуя рекомендациям и создавая структуру HTML с доступным контентом, мы можем гарантировать, что большинство пользователей действительно смогут использовать наши приложения.
Как узнать, что мне нужно протестировать в моем приложении?
При тестировании приложения важно учитывать, что необходимо протестировать, чтобы оптимизировать взаимодействие с пользователем. Библиотека тестирования React помогает в этом, сосредотачиваясь на взаимодействии с пользователем, а не на конкретных деталях реализации компонентов. Вот несколько ключевых моментов, которые следует учитывать при тестировании приложения:
- Убедитесь, что компонент отображается без ошибок. Это гарантирует отсутствие синтаксических ошибок и определение всех переменных.
- Проверьте вывод компонента. Учитывая определенные реквизиты, каков ожидаемый результат? Убедитесь, что компонент отображает правильную информацию.
- Тестируйте такие события, как onClick, onChange и другие. Убедитесь, что эти события работают правильно и вызывают указанные функции с правильными аргументами.
Изучение различных способов запроса элементов в библиотеке тестирования React: советы по выбору правильного метода и времени его использования.
getBy...используется только тогда, когда элемент присутствует в компоненте. Если элемент не найден, он вернет ошибку.
queryBy...используется только тогда, когда элемент отсутствует, но вскоре появится в компоненте, например, сообщение об ошибке, которое вы хотите показать пользователям.
findBy...используется для асинхронных элементов, которые в конечном итоге будут присутствовать в компоненте, например, выборка.
Я создал это приложение Todo, в котором мы можем практиковать все, что упоминалось выше.
Приложение имеет несколько функций, которыми могут воспользоваться пользователи. При первом использовании пользователь увидит заголовок, форму отправки задач и кнопку. Поле ввода будет пустым, и пользователь сможет ввести свою задачу.
Давайте протестируем наш компонент заголовка.
Чтобы создать первый тест:
- Создайте файл с именем вашего компонента, например Heading.test.jsx.
- Импортируйте компонент, который хотите протестировать. См. строку № 2 в примере.
- Импортируйте API рендеринга и экран из библиотеки тестирования React. Render API отображает компонент, а экран запрашивает элементы.
Есть две функции, о которых следует помнить при написании тестов.
Функция describe помогает сгруппировать список тестов. Это необязательно, но рекомендуется. Обычно передается имя компонента, который вы хотите протестировать. См. пример ниже, строка № 5.
Функция test оборачивает фактический отдельный тест.
Первый тест, начиная со строки №6, проверяет, что компонент Heading правильно отображает элемент заголовка (<h1>) при первом рендеринге. Он делает это, используя функцию render из @testing-library/react для рендеринга компонента Heading с реквизитом title, а затем использует функцию screen.getByRole для поиска элемента заголовка в визуализируемом компоненте. Наконец, он использует функцию expect, чтобы подтвердить, что элемент заголовка присутствует в документе.
Второй тест, начинающийся со строки №12, проверяет, что реквизит title, переданный компоненту Heading, правильно отображается как текстовое содержимое элемента заголовка. Это делается путем рендеринга компонента Heading и поиска элемента заголовка, как и раньше. Затем он использует функцию expect, чтобы утверждать, что текстовое содержимое элемента заголовка равно реквизиту title, переданному компоненту Heading.
В целом, эти тесты проверяют, что компонент Heading отображает элемент заголовка и отображает правильное текстовое содержимое при его отображении.
Способ узнать роли, доступные в моем компоненте.
Поскольку это небольшой компонент, мы смогли использовать функцию screen.getByRole('heading'), чтобы найти роль заголовка, но большую часть времени у вас будет много ролей в ваших компонентах, и сложно знать все роли HTML наизусть.
Чтобы получить списки ролей, напечатанные в вашем терминале, вы также можете использовать API logRoles.
- Импортируйте API logRole из библиотеки тестирования, как показано в примере ниже в строке № 2.
- Деструктурируйте контейнер из рендера, как в примере ниже строки №7.
При запуске ваших тестов будет напечатан список правил в вашем компоненте.
После того, как я провел свой тест, я смог попасть в список ролей. В моем случае у заголовка есть только одна роль.
Как видите, есть также тег имени, который представляет собой текст внутри тега h1 HTML.
Одним из полезных способов запроса элементов в библиотеке тестирования React является использование значения acessible name. Доступное имя — это текст, добавляемый внутри тега HTML.
Это позволяет нам ориентироваться на конкретный элемент по роли и доступному имени, даже если присутствует несколько элементов с одной и той же ролью.
Обратите внимание, что это должно быть вашим главным предпочтением, когда дело доходит до запроса элемента. Вспомогательные технологии могут громко говорить о ценности внутри HTML. Если вы не можете выполнить запрос, используя доступное значение имени, возможно, ваш пользовательский интерфейс недоступен.
Я добавил дополнительный HTML-тег h2 в компонент Heading.jsx, см. пример ниже строки №8.
Если мы попытаемся запросить заголовок только по роли заголовка, как мы сделали в приведенном выше примере, мы получим ошибку при запуске наших тестов, потому что в компоненте есть более одной роли заголовка.
Вам нужно будет сделать запрос, используя screen.getByAllRole('heading'), затем вам нужно будет получить позицию элемента, который вы хотите получить. Иногда это может сбивать с толку.
Вот пример компонента:
Вот пример запроса для каждой роли заголовка от accessible name.
При запросе для получения h2 я использую регулярное выражение, которое также поддерживается библиотекой тестирования React в строке № 12.
Это может быть особенно полезно при работе с большими и сложными компонентами, выполняющими одну и ту же роль. Используя accessible name, мы можем гарантировать, что нацеливаемся на правильный элемент, и избежать возможной путаницы.
Тестирование компонента формы Todo
Мы будем тестировать наш компонент формы, который отвечает за то, чтобы пользователь мог создавать и сохранять задачи.
Вот краткое изложение функциональных возможностей приложения:
- Когда пользователь пишет задачу и нажимает кнопку «Сохранить», он берет текст задачи и сохраняет его в бэкэнде.
- В то же время он выполнит выборку, чтобы получить сохраненную задачу и отобразить ее пользователю.
- После завершения выборки мы очищаем ввод.
- Он покажет пользователю задачу, которую он написал.
- Он позволяет пользователям помечать задачи как «выполненные», нажимая на них.
Я использую React Bootstrap, а также решил использовать fetch вместо AXIOS или другой библиотеки fetch. Не стесняйтесь использовать все, что вам нравится.
Вот наш взгляд на тесты для компонента TodoForm.
Заключение
Я рассмотрел все функции моего приложения todo. Имейте в виду, что важно разрабатывать тесты так, чтобы они отражали то, как будет использоваться приложение. Это не только сделает приложение более удобным для пользователя, но и предоставит более полный отчет о покрытии.
