1

2 つのアクションに分割された非同期アクション クリエーターがあります。1 つはアクションの開始を通知し、もう 1 つは終了を通知します。非同期アクション作成者の途中の Web 要求は、最初の同期ディスパッチによって設定された値に依存します。

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)))
  };
}

redux-mock-store のディスパッチの実装はかなりまばらで、(明らかな) 後から考えると、モック化されたストアにレデューサーを渡すことはありません。

これは、最初のdispatch呼び出しが、2 番目のディスパッチ呼び出しが依存する状態を更新する可能性がないことを意味します。次に作成する Web リクエストには、非同期アクション コールから更新された値ではなく、toと日付の元の値が含まれます。from

内のパラメータにさらに変換が適用される可能性があるため、 に渡されたfromおよびの値を直接使用することは避けたいと思います。willの結果に直接依存することで、さまざまな方法でフィルタリングするいくつかの同様のメソッドを DRY することもできます。tochangeFilterchangeFilterRequestgetState

これらのタイプのテストで従うべきパターンはありますか? アクションクリエーターを構築する別の方法はありますか?

4

1 に答える 1

1

単体テストは正確で、テストしたい機能の範囲のみに焦点を当てる必要があると思いますchangeFilter. changeFilterRequesthowactiveUsersが計算されて store に追加される方法をテストするための別の単体テストがあると仮定するとactiveUsers、ディスパッチの副作用としてストアで作成されるという事実は、 計算方法を気にするべきではないためchangeFilterRequest、テストの範囲外にする必要があります。に渡すとの値に必ずしも依存しないモック ストアにダミーの値を安全に追加し、関数がストアからその値を適切に読み取って に渡すことを確認できると思います。changeFilteractiveUsersactiveUserstofromchangeFilterRequestactiveUsersParams

そうは言っても、すべてのアクションが純粋になるため、モックを作成したり副作用をテストしたりすることなく、これらの種類のアクションを簡単にテストできるという理由だけで、非同期操作を処理redux-sagaする代わりに強くお勧めします。redux-thunk

于 2016-11-10T16:52:25.513 に答える