Как протестировать сайты и приложения React
Как протестировать сайты и приложения React

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

Библиотека тестирования – это группа утилит, которую разработчики используют для написания отдельных тестов для компонентов приложения. Некоторые из основных частей теста:

  • Описание: описывает суть теста
  • Используйте / Рендер: использует компонент в среде, где он может быть протестирован
  • Дразнящий: создает притворные функции, чтобы вы могли проверить свои предположения

В этой статье я собираюсь изучить некоторые примеры из библиотеки React Testing, чтобы помочь вам начать работу с этим ценным способом повышения надежности вывода вашего кода, а также обеспечения того, чтобы ваш код не выдавал любые неприятные сюрпризы, как только он поступит в производство.

01. Начните с библиотеки тестирования React

Я собираюсь использовать create-реагировать на приложение для этой демонстрации, потому что оно уже поставляется с предварительно настроенной библиотекой тестирования. Если вы используете Gatsby или пользовательские настройки, вам может потребоваться выполнить некоторые настройки, прежде чем вы начнете использовать библиотеку тестирования.

Для начала давайте создадим новое приложение. Если у вас уже есть последняя версия Node.js, вы можете выполнить следующую команду, не устанавливая ничего другого в глобальном масштабе:

npx create-react-app netmag-javascript-testing

02. Решите, что тестировать

Представьте, что у нас есть простой компонент, скажем, кнопка с некоторым состоянием. Какие вещи нужно тестировать в таком компоненте, как этот?

Внешний вид компонента:

Мы не хотим, чтобы что-то неожиданно изменилось после написания нашего компонента. Итак, мы собираемся написать тест снимка, чтобы понять, как он рендерится. Затем, если что-то изменится, мы увидим это быстро без ручного или визуального теста. Это отлично подходит для компонентов, которые состоят из множества более мелких компонентов: вы можете быстро увидеть, когда (и где) его внешний вид был затронут.

Различные ветви, которые делают:

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

Эти функции вызываются как и ожидалось:

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

03. Напишите свой первый тест

(Изображение: © Бен Рид)

Давайте напишем наш первый тест. Создайте новый файл с именем MyComponent.unit.test.js в той же папке, что и компонент. После добавления test.js он будет автоматически выбран библиотекой тестирования. Содержимое этого файла ниже:

import React from ‘react’ import { render } from ‘@testing-library/react’ import MyComponent from ‘./MyComponent’ describe(‘the ’, () => {     // tests go here })

Первое, на что я хочу обратить ваше внимание, это описывают () функция, которая принимает два аргумента: первый – это строка, которую вы можете использовать, чтобы лучше описать – как текстовую строку – что будет делать ваш тест. В нашем случае мы просто сказали, что это должно сделать. Это очень полезно, когда кто-то еще смотрит на ваш код или вы должны помнить, что вы сделали на более позднем этапе. Написание хороших описательных утверждений – это форма документации кода и еще одна веская причина для написания тестов.

Второй аргумент – ваши тесты. описывают () Функция будет запускать все эти тесты один за другим.

 

04. Используйте функцию очистки

Давайте введем вспомогательную функцию под названием beforeEach (), Мы должны использовать это, потому что каждый раз, когда мы что-то делаем с компонентом, нам нужна свежая копия без реквизитов, которые мы ранее передали, все еще существующие в компоненте. Или нам может понадобиться перерисовать компонент: beforeEach () делает это для нас, и мы можем передать ему функцию очистки.

import { render, cleanup } from ‘@testing-library/react’ ... describe(‘the component should render’, () => {   beforeEach(cleanup) }

05. Написать тест снимка

(Изображение: © Бен Рид)

На этом шаге мы собираемся «смонтировать» наш компонент (или отрендерить его).

describe(‘the component should render’, () => {   beforeEach(cleanup)   it(‘renders with basic props’, () => {     render()   }) }

Этот рендер предоставляет нам доступ ко всем отображаемым свойствам скомпилированного компонента. Это может быть хорошо, чтобы бросить это в console.log () так что вы можете увидеть более четко, что он делает.
Если вы это сделаете, вы увидите, что есть несколько полезных свойств, которыми мы можем воспользоваться здесь. Я собираюсь сделать утверждение (сделать тестируемое объявление) и проверить его, извлекая контейнер. Контейнер «содержит» узлы DOM (весь HTML), связанные с компонентом.
it(‘renders with basic props’, () => {     const { container } = render() })

Теперь у нас есть доступ к контейнеру, как я могу сказать, что он отображается согласно моему утверждению? Добавив тест снимка.

Думайте о снимке как о фотографии. Он делает снимок нашего компонента в определенный момент времени. Затем всякий раз, когда мы вносим изменения в код, мы видим, соответствует ли он исходному снимку. Если это произойдет, мы можем быть уверены, что ничего не изменилось в компоненте. Однако, если это не так, мы могли бы обнаружить проблему, возникшую в другом компоненте, которую мы могли не заметить ранее:

06. Тест свойств

Реквизиты или свойства компонента также можно протестировать с помощью моментальных снимков. Тестирование различных реквизитов, которые вы предоставляете вашему компоненту, обеспечит вам больший охват и уверенность. Вы никогда не знаете, когда требование будет означать, что реквизиты вашего компонента будут реорганизованы, и окончательный результат изменится.

Добавьте следующий объект в начало вашего файла:

const lightProperties = {     backgroundColour: ‘white’,     textColour: ‘darkblue’ }

Мы определяем свойства объекта и затем используем оператор распространения (три точки, за которыми следует имя объекта: … lightproperties) потому что мы можем передать только один аргумент при рендеринге таким образом. Также полезно посмотреть, какие свойства вы передаете изолированно:

it(‘renders with basic props’, () => {         const { container } = render(       )      expect(container).toMatchSnapshot()     })     it(‘renders with the light version props’, () => {         const { container } = render(                      )         expect(container).toMatchSnapshot()     }) 

07. Тест изменений в пользовательском интерфейсе

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

Это знакомит нас с важной концепцией использования библиотеки тестирования: мы здесь не для проверки состояния или работы нашего компонента. Мы здесь, чтобы проверить, как люди собираются использовать компонент и соответствует ли он их ожиданиям.

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

Давайте представим, что мы тестируем результат функции, которая меняет пользовательский интерфейс с темного режима на светлый. Вот компонент:

const modeToggle = () => {     const (mode, setMode) = useState(‘light’)    const toggleTheme = () => {      if (theme === ‘light’) {        setTheme(‘dark’)      } else {        setTheme(‘light’)      }    }     return (                    Toggle mode              ) } 

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

return (            Toggle mode      

Вы заметили, что мы добавили новый атрибут данная TestID на кнопку? Вот как вы можете это проверить. Сначала импортируйте новую функцию fireEvent из библиотеки тестирования:

import { cleanup,            fireEvent,            render  } from ‘@testing-library/react’ 

Мы можем использовать эту функцию, чтобы проверить, есть ли изменения в пользовательском интерфейсе, и что эти изменения согласованы:

it(‘renders with basic props’, () => {     const { container } = render(   )  expect(container).toMatchSnapshot() }) it(‘renders the light UI on click’, () => {     const { container, getByTestId } = render()     fireEvent.click(getByTestId(‘mode-toggle’))     expect(container).toMatchSnapshot() })

Это здорово: нам не нужно вручную заходить на сайт и осматриваться, затем нажимать кнопку и осматриваться второй раз – во время которого, вы можете признать, вы, вероятно, забудете или пропустите что-то! Теперь мы можем быть уверены, что при одинаковом входном сигнале мы можем ожидать такой же выходной сигнал в нашем компоненте.Когда дело доходит до проверки идентификаторов, мне лично не нравится использовать данная TestID найти что-то в DOM. В конце концов, цель тестов – имитировать то, что делает пользователь, и тестировать, что происходит, когда он это делает. данная TestID Это похоже на читерство – хотя данные, скорее всего, пригодятся вашему инженеру по обеспечению качества (см. раздел «Роль инженеров по обеспечению качества»).Вместо этого мы могли бы использовать getByText () и передать текст нашей кнопки. Этот метод будет более специфичным для поведения.

08. Шутка и шпионская функция

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

Мне не нужно проверять, каков результат этого модуля. Мне нужно проверить, что моя функция работает, как ожидалось. Для получения дополнительной информации о причинах этого см. Раздел «Тесты модулей и интеграции». В этом случае мы могли бы «смоделировать» эту функцию:

const getPiValue = jest.fn() it(‘calls the function on click’, () => {     const { container, getByTestId } = render()     fireEvent.click(getByTestId(‘mode-toggle’))     expect(getPiValue).toHaveBeenCalledTimes(1)   ) })

Функция toHaveBeenCalledTimes () является одной из многих вспомогательных функций в библиотеке тестирования, которые позволяют нам

проверить вывод функций. Это позволяет нам не только охватывать наши тесты только тем модулем, который мы хотим протестировать, но также означает, что мы можем «шпионить» или видеть, что делает наша функция, когда она вызывает эту функцию.

09. Начать тестирование приложений React

(Изображение: © React Testing Library)

Написание тестов может показаться немного сложным для начала. Я надеюсь, что этот урок дал вам больше уверенности, чтобы попробовать его. С тех пор, как я начал писать тесты для своих приложений, я действительно не могу вернуться: я могу отдыхать легче, зная, что оставляю гораздо лучшее наследство для тех, кто будет использовать мою работу в будущем.

Чтобы узнать больше о том, как протестировать свои компоненты, посетите Библиотека тестирования React или примеры тестирования React, Если вы ищете какие-то курсы, которые помогут вам начать работу, один из них Кент К Доддс (который написал и поддерживает React Testing Library) популярен. Мне также понравился этот материал в «Учебниках повышения уровня», именно он заставил меня начать писать тесты для своего кода.

Do NOT follow this link or you will be banned from the site!
WeCreativez WhatsApp Support
Наша служба поддержки клиентов готова ответить на ваши вопросы.
Привет, чем я могу помочь?