Единичное тестирование приложений React/Redux

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

Имеет ли смысл тестировать создателей простого действия, которые просто возвращают объект с полями type и payload? Для меня это пахнет тестами getter/setter в приложениях OO.
В случае тестирования асинхронного действия, следует ли проверять соответствующие действия успеха и отправляться? Опять же, с запросами HTTP, издевающимися, кажется, что это просто проверка контейнеров mocks, а не поведение приложения.
Если тестирование фокусируется на редукторах, поскольку они отвечают за переход состояния, значит для поведения подключенных компонентов?
Возможно, вместо того, чтобы тестировать редукционные кишки приложения, он должен тестироваться больше на уровне компонентов? Какие аспекты компонента следует тестировать, когда? Являются ли эти тесты хрупкими?

Я бы хотел услышать некоторый опыт людей, которые используют Redux/React в производстве и активно практикуют тестирование.

Ответ 1

Я отвечу на каждый вопрос по очереди, просто с разным уровнем детализации, соответствующим моему опыту.

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

Если вы используете абстракцию наподобие redux-actions, как я на самом деле использовал редукс, то на самом деле это не так. Если вы снова и снова возвращаете объекты с одними и теми же свойствами, просто установите простой тестовый пример, который прокручивается над создаваемыми создателями действия, вызывает их со значениями и проверяет возвращаемые типы объектов. Overkill для нескольких, но становится дешевой проверкой здравомыслия, когда у вас много создателей действий. Пример:
```
for (var i = 0; i < actions.length; i++) {
  let action = actions[i](testData);
  expect(action).to.have.property('type');
  expect(action).to.have.property('payload');
}
```
Смутно сформулированный вопрос, но в любом случае опыт научил меня чрезмерно проверять вещи, связанные с сетью. Закройте крайние случаи из-за тайм-аутов и бросьте несколько ожиданий на форму реакции, идущей на редукторы, и порядок, в котором они были вызваны.
Да, он должен сосредоточиться на редукторах. Это самый важный вопрос, связанный с одной из причин успешности сокращения. Все это простые функции, объединенные в мощные и легко аргументированные функции (редукторы).

Итак, если бы у нас было:
```
const reducer = combineReducers({
  a: reduceA,
  b: reduceB
})
```
Затем проверьте каждое поведение редуктора (reduceA и reduceB) в отдельных тестовых случаях. Вы все равно хотите протестировать возвращаемые результаты и их формы, но всегда старайтесь разбить редукторы как на реализацию, так и на тестирование.
Как и раньше, вы должны использовать малые функции и их тестируемые реализации перед тем, как их использовать в определенной структуре компонентов (здесь предполагается, что response.js). Если вы следуете рекомендациям, приведенным в docs

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

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

Ответ 1

Ответ 2