React/Redux 应用程序的单元测试答案

【问题标题】：Unit testing of React/Redux applicationsReact/Redux 应用程序的单元测试
【发布时间】：2016-02-27 00:45:52
【问题描述】：

我目前正在研究基于 Redux/React 的应用程序的测试方法。我浏览了有关测试的 redux 教程，但仍有疑问：

测试简单的动作创建者是否有意义，它只返回一个带有type 和payload 字段的对象？对我来说，它闻起来像 OO 应用程序中的 getter/setter 测试。
在测试异步操作的情况下，是否应该检查相应的操作是否成功并被分派？同样，在模拟 HTTP 请求时，它似乎只是在测试模拟容器，而不是应用程序行为。
是否应该在 reducer 中进行测试，因为它们负责状态转换，意味着连接组件的行为？
也许与其测试应用程序的 redux 内脏，不如在组件级别上进行更多测试？什么时候应该测试组件的哪些方面？这些测试脆弱吗？

我想听听一些在生产中使用 Redux/React 并积极练习测试的人的经验。

【问题讨论】：

2.我认为在调度多个动作的情况下值得测试：FOO_LOADING、FOO_RECEIVED。检查它们是否以正确的顺序与正确的有效负载一起发送。

标签： unit-testing reactjs tdd redux

【解决方案1】：

您可以尝试使用redux-actions-assertions 来测试动作和动作创建者。它允许编写一行可读的断言，并避免存储准备阶段。

【讨论】：

【解决方案2】：

我将依次回答每个问题，只是根据我的经验提供不同程度的详细信息。

tl dr：专注于应用程序特定的行为和功能测试，让库担心 redux 实现细节并在组件中使用之前测试小型化简器功能。

如果你像我最初使用 redux 那样使用像 redux-actions 这样的抽象，那么就不是这样了。如果您一遍又一遍地手动返回具有相同属性的对象，只需设置一个简单的测试用例，该用例循环暴露的动作创建者，用值调用它们并检查返回的对象类型。对少数人来说太过分了，但当你有很多动作创造者时，它就成了一种廉价的理智检查。例如：
```
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');
}
```
一个措辞令人困惑的问题，但无论如何经验教会我过度测试与网络打交道的事物。覆盖由于超时而导致的边缘情况，并在返回到 reducer 的响应的形状以及调用它们的顺序上提出一些期望。
是的，它应该专注于减速器。这是最重要的问题，因为它关系到 redux 成功的原因之一。一切都是简单的函数组合成强大且易于推理的函数（减速器）。

如果我们有：
```
const reducer = combineReducers({
  a: reduceA,
  b: reduceB
})
```
然后在单独的测试用例中测试每个 reducer（reduceA 和 reduceB）的行为。您仍然希望测试返回的结果及其形状，但始终尝试在实现和测试中分解减速器。
和以前一样，您应该在使用特定组件框架（这里假设为 react.js）之前使用小函数并测试它们的实现。如果您遵循docs 中给出的建议

建议只有应用程序的顶级组件（例如路由处理程序）才知道 Redux。它们下面的组件应该是展示性的，并通过道具接收所有数据。

那么你所要做的就是测试顶级组件是否传入了 redux 的 dispatch，然后测试简单的组件是否调用像 onClick 这样的处理程序，或者从你的商店中取出正确的状态，但这些应该只需要对道具的形状和价值进行简单的间谍或断言，而不是真正与 redux 相关。

【讨论】：