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

Question

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

1. 测试普通的动作创建者是否有意义，它只返回一个带有type和payload字段的对象？ 对我来说，它在OO应用程序中闻起来像getter/setter测试。

2. 在测试异步操作的情况下，您是否应该检查相应的成功操作并进行调度？ 再次，对于模拟的HTTP请求，它似乎只是测试模拟容器，而不是应用程序行为。

3. 测试应该集中在减速器上，因为它们负责状态转换，是连接组件行为的手段吗？

4. 也许不是测试应用程序的redux内核，而是应该在组件级别上进行更多测试？ 组件的哪些方面应该在何时测试？ 那些测试是否脆弱？

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

Answer 1

我将依次对每个问题做出回应，只是根据我的经验提供不同程度的细节。

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

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

2. 一个令人困惑的措辞问题，但无论如何，经验教会我过度测试处理网络的事情。 由于超时而覆盖边缘情况，并且会对减速器的响应形状以及它们的调用顺序提出一些预期。

3. 是的，它应该专注于减速器 。 这是最重要的问题，因为它与redux成功的原因之一有关。 一切都是简单的功能，组合成功能强大且易于理解的功能（减速器）。

   所以如果我们有：

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

   然后在单独的测试用例中测试每个reducer的（ reduceA和reduceB ）行为。 您仍然希望测试返回的结果及其形状，但总是试图在实现和测试中分解reducers。

4. 和以前一样，在使用特定组件框架（这里假设为react.js）之前，您应该使用小函数并测试它们的实现。 如果您遵循文档中给出的建议

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

   然后你需要测试的是顶层组件传递redux的dispatch ，然后测试简单组件是否调用像onClick这样的处理程序，或者从你的商店中取出正确的状态，但这些只需要是简单的间谍或断言道具的形状和价值，与真正的redux无关。

Answer 2

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