Единичное тестирование приложений 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, или вырывают правильное состояние из вашего магазина, но они должны иметь только быть простыми шпионами или утверждениями о форме и значении реквизита, не относящихся к редукции.

Ответ 2

Вы можете попытаться использовать redux-actions-assertions для тестирования действий и создателей действий. Он позволяет писать однострочные читаемые утверждения и избегать фазы подготовки к хранению.