Редукторы
Просто напомним, что такое reducer, прежде чем мы перейдем к тестированию и написанию кода. Документация Redux по-прежнему великолепна, на самом деле она хорошо описывает модульные тесты, вам даже не нужно читать этот пост. Подводя итог, редуктор - это чистая функция, которая принимает предыдущее состояние и действие и возвращает следующее состояние.
Если вам интересно узнать, как тестировать действия async redux, ознакомьтесь с
Чистые функции
Поскольку это чистая функция, ее легко протестировать. Это функция, которая не вызывает побочных эффектов; при одном и том же вводе всегда будет возвращать один и тот же вывод; не полагается на внешнее состояние.
Что тестировать
Обычно reducer состоит из начального состояния и оператора switch для обработки каждого действия. Мне нравится разбивать свой магазин на разные суб-магазины и иметь отдельные редукторы для каждого суб-магазина. Иногда один переключатель / случай может обрабатывать несколько действий, потому что бизнес-логика одинакова, и результат должен быть одинаковым. В некоторых примерах GET_POST и UPDATE_POST должны обновлять одно и то же хранилище и давать одинаковый результат.
Важно тестировать редукторы. Вот где должна происходить бизнес-логика и где новое состояние приложения формируется на основе внешнего (API) или внутреннего ответа.
Boilerplate
Как и любой модульный тест, он начинается с настройки шаблона и написания пустых тестов, чтобы обозначить, что нужно тестировать. Мне нравится проверять начальное состояние, а затем каждый переключатель / случай в редукторе, чтобы увидеть, будет ли action.payload создавать ожидаемый хранилище. Если остановиться и подумать - все просто.
Добавить тесты и фиктивные данные
Отсюда мы можем просто начать заполнять тесты один за другим. Мне также нравится создавать фиктивные файлы и сохранять ответ API во время тестирования. Так что я могу протестировать «реальные» данные. Эта стратегия выявила несколько случайных изменений API, когда ответ был изменен без предупреждения. Вместо того, чтобы обвинять кого-либо, мы можем просто взглянуть на фиктивные данные и увидеть, что ожидается от клиентской части.
Наличие модульных тестов для всех редукторов предотвратит любые проблемы, связанные с глобальным состоянием приложения. Это особенно полезно, если существует много разных вызовов API, и каждый вызов изменяет состояние. Легко сломать все состояние приложения с помощью небольшого рефакторинга, даже не осознавая этого.
