如何测试依赖先前调度调用的异步操作创建器?

时间:2016-11-10 14:45:32

标签: javascript unit-testing redux redux-thunk redux-mock-store

我有一个异步动作创建器,它被分成两个动作,一个用于表示动作的开始,另一个用于表示结束。异步操作创建者中间的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))) }; } 调用无法更新第二个调度调用所依赖的状态。然后,我们制作的网络请求包含dispatchto日期的原始值,而不是异步操作调用中的更新值。

我希望避免直接使用传递给from的{​​{1}}和from值,因为可能会对to中的参数应用进一步的转换。直接依赖changeFilter的结果也可以让我干掉少数几种以不同方式过滤的类似方法。

对于这些类型的测试,我应该遵循哪些模式?我应该采用不同的方式构建我的动作创作者吗?

1 个答案:

答案 0 :(得分:1)

我认为您的单元测试应该是精确的,并且只关注您要测试的函数的范围changeFilter。假设您有changeFilterRequest的另一个单元测试来测试如何计算activeUsers并将其添加到商店,那么在商店中创建activeUsers作为分派的副作用{{1}由于changeFilterRequest不应该关心如何计算changeFilter,因此应该超出测试范围。我认为您可以安全地在模拟商店中为activeUsers添加任何虚拟值,该值不一定取决于您传递给activeUsers的{​​{1}}和to的值并制作确保您的函数正在从商店中正确读取该值并将其传递给from

尽管如此,我强烈建议changeFilterRequest替代activeUsersParams来处理异步操作,因为它可以轻松测试这些操作,而无需创建模拟或测试副作用,因为所有操作都是如此将是纯洁的。