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

我正在调查基于Redux / React的应用程序的测试方法。我通过了redux教程的测试，但仍然有问题：

>测试简单的动作创建者，只返回一个类型和有效负载字段的对象是否有意义？对于我来说，它在OO应用程序中闻起来像吸气剂/凝结剂测试。
>在测试异步动作的情况下，是否应该检查相应的成功动作并发出？再次，HTTP请求嘲笑，似乎只是测试mocks容器，而不是应用程序行为。
>在减速器中应该测试重点，因为它们负责状态转换，意味着连接组件的行为？
>而不是测试应用程序的减少，应该在一个组件级别上进行更多的测试？什么方面的组件应该测试什么时候？那些测试是否脆弱？

我想听一些使用Redux / React的人在生产中积极地进行测试的经验。

我会依次对每个问题做出回应，只是根据我的经验对应的不同级别的细节。

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

>如果像最初使用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');
}

>一个令人困惑的措辞问题，但无论如何，经验告诉我过度测试处理网络的事情。由于超时而引起的边缘案例，并且引用了一些期望对减速器的响应的形状以及它们被调用的顺序。
>是的，应该专注于reducers。这是最重要的问题，它与redux成功的原因之一有关。一切都是简单的功能，结合成功能强大，容易推理的功能(reducers)。

所以如果我们有：

const reducer = combineReducers({
  a: reduceA,b: reduceB
})

然后在单独的测试用例中测试每个reducer的(reduceA和reduceB)行为。您仍然需要测试返回的结果及其形状，但总是尝试分解实现和测试中的reducer。
>像以前一样，您应该使用小功能，并在使用特定组件框架(这里假定为react.js)之前对其实现进行测试。如果你遵循docs的建议

It is advisable that only top-level components of your app (such as route handlers) are aware of Redux. Components below them should be presentational and receive all data via props.

那么所有你需要测试的就是将redux的dispatch传入的顶级组件，然后测试如果简单的组件调用像onClick这样的处理程序，或者从你的存储中挑选出正确的状态，但是这些只能是简单的间谍或断言道具的形状和价值，并不是真的相关。