我有一个异步动作创建器,它被分成两个动作,一个用于表示动作的开始,另一个用于表示结束。异步操作创建者中间的Web请求依赖于第一个同步调度设置的值:
data
implementation of redux-mock-store's dispatch非常稀疏,而且(显而易见)后见之明,我们从未将任何减速器传递给模拟商店。
这意味着第一个export function changeFilter(from, to) {
return (dispatch, getState, { fetch }) => {
// Updates the state with the new values and sets a loading flag
dispatch(changeFilterRequest(from, to));
// Now I want to use those newly-set values to build a query
// string. However, the stubbed implementation of `dispatch`
// doesn't use reducers, so `getState` continues to return the
// original value.
const { activeUsers } = getState();
return doSomeWebRequest(fetch, activeUsersParams(activeUsers))
.then(response => dispatch(changeFilterSuccess(response)))
};
}
调用无法更新第二个调度调用所依赖的状态。然后,我们制作的网络请求包含dispatch
和to
日期的原始值,而不是异步操作调用中的更新值。
我希望避免直接使用传递给from
的{{1}}和from
值,因为可能会对to
中的参数应用进一步的转换。直接依赖changeFilter
的结果也可以让我干掉少数几种以不同方式过滤的类似方法。
对于这些类型的测试,我应该遵循哪些模式?我应该采用不同的方式构建我的动作创作者吗?
答案 0 :(得分:1)
我认为您的单元测试应该是精确的,并且只关注您要测试的函数的范围changeFilter
。假设您有changeFilterRequest
的另一个单元测试来测试如何计算activeUsers
并将其添加到商店,那么在商店中创建activeUsers
作为分派的副作用{{1}由于changeFilterRequest
不应该关心如何计算changeFilter
,因此应该超出测试范围。我认为您可以安全地在模拟商店中为activeUsers
添加任何虚拟值,该值不一定取决于您传递给activeUsers
的{{1}}和to
的值并制作确保您的函数正在从商店中正确读取该值并将其传递给from
。
尽管如此,我强烈建议changeFilterRequest
替代activeUsersParams
来处理异步操作,因为它可以轻松测试这些操作,而无需创建模拟或测试副作用,因为所有操作都是如此将是纯洁的。