React / Redux应用程序的单元测试-Java 学习之路

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

测试普通的动作创建者是否有意义，只返回一个带有 type 和 payload 字段的对象？对我来说，它在OO应用程序中闻起来像 getter/setter 测试 .
在测试异步操作的情况下，您是否应该检查相应的成功操作并进行调度？再次，对于模拟的HTTP请求，它似乎只是测试模拟容器，而不是应用程序行为 .
应该将测试重点放在减速器上，因为它们负责状态转换，是指连接组件行为的手段？
也许不是测试应用程序的redux内核，而是应该在组件级别上进行更多测试？组件的哪些方面应该在何时测试？那些测试是否脆弱？

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

2 回答

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

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');
}
```
- 一个令人困惑的措辞问题，但无论如何，经验教会我过度测试处理网络的事情 . 由于超时而覆盖边缘情况，并且会对减速器的响应形状以及它们的调用顺序提出一些预期 .
- 是的，它应该 focus on reducers . 这是最重要的问题，因为它与redux成功的原因之一有关 . 一切都是简单的功能，组合成功能强大且易于理解的功能（减速器） .
所以如果我们有：
```
const reducer = combineReducers({
  a: reduceA,
  b: reduceB
})
```
然后在单独的测试用例中测试每个reducer的（ reduceA 和 reduceB ）行为 . 您仍然希望测试返回的结果及其形状，但总是试图在实现和测试中分解reducers .
- 和以前一样，在使用特定组件框架（这里假设为react.js）之前，您应该使用小函数并测试它们的实现 . 如果您遵循docs中给出的建议
建议只有应用程序的顶级组件（例如路由处理程序）才能识别Redux . 它们下面的组件应该是表示性的，并通过道具接收所有数据 .

然后你需要测试的是顶层组件，传递redux的 dispatch ，然后测试简单组件是否调用像 onClick 这样的处理程序，或者从你的商店中取出正确的状态，但这些只需要是简单的 Spy 或断言道具的形状和 Value ，与真正的redux无关 .
回复于 2024-04-27T10:31:51+08:00
1

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

回复于 2024-04-27T10:31:51+08:00

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

2 回答

相关问题