Итак, скажем, что у меня есть редуктор с несколькими ветвями, но каждая ветвь достаточно похожа на генератор с функцией factory. Итак, я создаю один:
import { combineReducers } from 'redux'
const createReducerScope = scopeName => {
const scope = scopeName.toUpperCase()
const contents = (state = {}, action) => {
switch (action.type) {
case `${scope}_INSERT`:
return { ...state, [action.id]: action.item }
default:
return state
}
}
const meta = (state = {}, action) => {
switch (action.type) {
case `${scope}_REQUEST`:
return { ...state, requesting: true }
case `${scope}_REQUEST_FAILURE`:
return {
...state,
requesting: false,
errorMessage: String(action.error)
}
case `${scope}_REQUEST_SUCCESS`:
return {
...state,
requesting: false,
errorMessage: null
}
default:
return state
}
}
return combineReducers({ contents, meta })
}
Что я использую для компоновки большего дерева состояний корневого уровня:
const products = createReducerScope('products')
const orders = createReducerScope('orders')
const trades = createReducerScope('trades')
const rootReducer = combineReducers({ products, orders, trades })
Это должно дать мне граф состояний, который будет выглядеть следующим образом:
{
products: { contents, meta },
orders: { contents, meta },
trades: { contents, meta }
}
Если бы я хотел протестировать это состояние, моим первым инстинктом является создание версии этой области в моем тестовом наборе, а затем проверка этого изолированного редуктора (только утверждение против ветвей contents
и meta
).
Усложнение заключается в том, что я пытаюсь также тестировать селектор, и все созданные мной селекторные схемы, кажется, предлагают эти две вещи:
- Вы инкапсулируете свое состояние, выбирая селектор и редукторы в том же файле.
-
mapStateToProps
нужно знать только две вещи: глобальное состояние и соответствующий селектор.
Итак, вот моя проблема: Сопряжение этих более или менее сложных редукторов с селекторами, зависящими от уровня корня, сделало мои тесты немного толстыми с шаблоном.
Не говоря уже о том, что записывающие селектора со знанием всего дерева чувствуют, что это бросает вызов точке попытки модульной редукции.
Я на 100% уверен, что мне не хватает чего-то очевидного, но я не могу найти какой-либо примерный код, который демонстрирует способ тестирования модульных редукторов и селекторов.
Если селектор, как правило, должен знать все глобальное состояние, но у вас есть редукторы, которые очень сложны, есть ли чистый, идиоматический подход к тестированию? Или, может быть, более сложный селекторный дизайн?