Важность написания эффективных тестов компонентов перед тестированием Redux с RTL

Библиотека тестирования React (RTL) – это комплексный инструмент для тестирования, предназначенный для проверки пользовательского интерфейса вашего приложения с точки зрения пользователя (дополнительную информацию о том, почему вам следует ее использовать, см. в моем предыдущем запись в блоге). Поскольку Redux тесно интегрирован с компонентами React, его обычно тестируют как часть тестов компонентов. Поэтому важно иметь четкое представление о том, как писать эффективные тесты компонентов с использованием RTL, прежде чем погрузиться в тестирование Redux с RTL.

Как только вы хорошо разберетесь в тестировании компонентов React с помощью RTL, вы можете начать думать о том, как протестировать свой магазин Redux и взаимодействие между вашими компонентами и магазином. Именно здесь тестирование с RTL может оказаться особенно полезным.

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

Модульные и интеграционные тесты

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

Традиционно модульные тесты определялись как тесты, которые изолировали одну единицу кода (например, функцию или класс) и имитировали все ее зависимости. Цель состояла в том, чтобы протестировать устройство изолированно, чтобы убедиться, что оно ведет себя должным образом при различных входных данных и условиях.

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

Когда дело доходит до тестирования Redux с RTL, важно учитывать, где проходят границы между функциональными единицами. С одной стороны, вы можете возразить, что один Redux-редюсер или создатель действий — это «модуль», который следует тестировать изолированно. С другой стороны, вы можете возразить, что само хранилище Redux — это единица, которую следует тестировать как единое целое, а также его взаимодействие с компонентами React.

В конечном счете, выбор между написанием «настоящих» модульных тестов или «общественных» модульных тестов с RTL зависит от целей вашей стратегии тестирования и конкретных требований вашего приложения. Давайте углубимся.

Когда писать социальные тесты?

Безусловно, самый важный способ обеспечить это — написать тесты, которые вызывают тестируемую систему так же, как ее пользователи; то есть делать вызовы к его общедоступному API а не к деталям его реализации. Если тесты работают так же, как и пользователи системы, по определению изменение, нарушающее тест, может также сломать пользователя. В качестве дополнительного бонуса такие тесты могут служить полезными примерами и документацией для пользователей.

Разработка программного обеспечения в Google

Чем больше ваши тесты походят на то, как используется ваше программное обеспечение, тем больше уверенности они могут дать вам.

– Кент С. Доддс 🌌 (@kentcdodds) 23 марта 2018 г.

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

Во-вторых, общительные тесты с RTL могут помочь уменьшить количество дублированных тестов и обеспечить более полный охват вашей кодовой базы за счет тестирования взаимодействия между различными единицами кода. Если вы уже написали тесты компонентов с RTL, вы можете использовать эти тесты для проверки взаимодействия между компонентами и хранилищем Redux. Это может сэкономить время и силы при написании дополнительных тестов с нуля. Забудьте о написании отдельных тестов для редьюсеров, действий, преобразователей, промежуточного программного обеспечения и всего прочего — создание модульных тестов только для компонента охватит все эти действующие лица Redux.

В-третьих, общительные тесты могут помочь улучшить ремонтопригодность вашего набора тестов за счет уменьшения количества фиктивных объектов, которые вам необходимо поддерживать. Если вы пишете изолированные модульные тесты, вам может потребоваться создать много фиктивных объектов для каждого модуля, что может занять много времени и привести к ошибкам. В отличие от этого, тесты на взаимодействие с RTL могут уменьшить потребность в фиктивных объектах и ​​упростить тестовый код.

И последнее но не менее важное. Написав общительные тесты, вы можете защитить свою кодовую базу в будущем и гарантировать, что ваши тесты будут продолжать работать, даже если вы внесете изменения в свою архитектуру — вообще говоря, вы сделаете свои тесты независимыми от фреймворка. Однажды вы можете решить заменить action thunks на потоковое промежуточное ПО rxjs, обновить свою архитектуру Redux, чтобы использовать инструментарий Redux, заменить Redux другим решением для управления состоянием или вообще избавиться от уровня Redux (добро пожаловать в рай!) — ваш модуль тесты должны пройти!

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

Когда писать изолированные модульные тесты для Redux?

Написание модульных тестов для Redux по-прежнему может быть важным, даже если вы также пишете социальные тесты с RTL. Вот несколько ситуаций, когда вам может понадобиться написать модульные тесты специально для Redux:

* При тестировании сложной логики в редьюсерах: хотя можно тестировать редьюсеры Redux с помощью компонентных тестов с RTL, иногда может быть удобнее написать изолированные модульные тесты для сложной логики редюсера. Это может помочь обеспечить правильное поведение редуктора, независимо от каких-либо конкретных взаимодействий компонентов.

* При тестировании побочных эффектов в промежуточном программном обеспечении Redux: если у вас есть собственное промежуточное программное обеспечение в вашем магазине Redux, вы можете написать изолированные модульные тесты, чтобы убедиться, что промежуточное программное обеспечение работает правильно. Допустим, у вас есть какое-то действие, которое запускается, когда пользователь переходит к определенным маршрутам. Эта логика обычно существует вне компонента и не может быть запущена через взаимодействие с пользовательским интерфейсом.

* Различия в количестве или порядке вызовов функции могут привести к нежелательному поведению. Допустим, у вас есть массовое действие thunk, которое реализует разнородное транзакционное сохранение нескольких связанных элементов — может быть важно, чтобы запросы DELETE выполнялись перед запросами POST. Вы можете возразить, что то же самое можно утверждать и в тестах компонентов, но это сделает их менее ориентированными на состояние и добавит избыточной сложности (нам придется анализировать всю полезную нагрузку API, поскольку у нас нет доступа к действиям Redux). Но это скорее компромисс, чем жесткое ограничение. Если вы чувствуете, что то же самое можно сделать в тестах компонентов с минимальными усилиями и с таким же уровнем уверенности, то почему бы и нет?

ПРИМЕЧАНИЕ. подход, при котором модульные тесты проверяют, как вызывается функция, без фактического вызова реализации функции, называется тестированием взаимодействия. Противоположной стратегией является государственное тестирование. При тестировании состояния вы визуализируете тестируемый компонент и проверяете, было ли отображено правильное значение (или элемент) или что какое-то другое состояние в тестируемом компоненте изменилось, как ожидалось. Всегда отдавайте предпочтение государственному тестированию! Но в некоторых случаях важно убедиться, что правильная конечная точка API с правильной полезной нагрузкой была вызвана после некоторого взаимодействия с пользовательским интерфейсом, вызванного тестом RTL в компоненте. Так что можно смешивать оба подхода в одном тесте:

expect(await screen.findByRole('input')).toHaveValue(expectedValue);
expect(fetchMock.mock.calls).toMatchSnapshot();

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

Заключение

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

В конечном счете, главное — найти баланс между различными подходами к тестированию и выбрать наиболее подходящий подход для каждого конкретного сценария. Объединив общие тесты с RTL и изолированными модульными тестами для Redux, вы можете создать надежный и всеобъемлющий набор тестов, который поможет обеспечить качество и надежность вашего приложения.

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

Вы также можете подписаться на меня в Twitter и < em>подключитесь к LinkedIn чтобы получать уведомления о новых сообщениях!

:::информация Первоначально опубликовано по адресу https://thesametech.com 18 апреля 2023 г.

:::