为什么我需要测试Redux实现，而我可以使用测试库测试DOM

Question

我无法理解整个测试过程。我使用的是测试库，我觉得只测试文本和标签很舒服，我觉得我不需要测试React或Redux中的任何实现，这就是我在React测试库文档中读到的，因为Enzyme迫使人们总是测试React实现。

现在，如果所有文本、标签和显示的值在我的测试中都是正确的，这意味着一切都应该正常，但不幸的是，当我使用Redux时，我总是被迫测试Redux实现(模拟存储、模拟还原器等)和异步行为，如获取数据等。

为什么我需要并被迫测试Redux实现，只要我可以测试显示的值，并且通过的测试将始终表明Redu实施在我的项目中正常工作？

Answer 1

我无法理解测试的整个过程

这是可以理解的。测试和软件质量保证是一个巨大的专业领域(不仅仅是视频游戏测试！)

我正在使用一个测试库，我觉得只测试文本和标签很舒服，我觉得我不需要测试React或Redux 中的任何实现

这是错误的态度。你所描述的是一种非常不严格的、草率的、随意的——最重要的是：肤浅的测试。

仅仅因为用户计算机屏幕上的数据显示是正确的，并不意味着它实际上是正确的。你怎么知道你实际上没有与模拟的UI交互，或者后端数据库实际上包含新数据？或者没有任何负面副作用(比如系统删除了其他所有-是的，这发生在我身上一次…)

打个比方，你说你很乐意乘坐一架经过测试的飞机，只要确保移动控制轭，屏幕上的飞机图标就会朝着正确的方向移动，即使飞机仍然牢牢地在地面上。我不想坐那架飞机。

现在，如果所有文本、标签、显示值在我的测试中都为真，这意味着一切都应该正常

不，不是。请参见上文。

但不幸的是，当我使用Redux时，我总是被迫测试Redux实现(模拟存储、模拟还原器等)和异步行为，如获取数据等。

是。你被迫做正确的事情。它被称为成功之坑。不要反抗，这是最好的。这些库、平台和框架是由比我们两人都更有软件设计经验的人设计的，所以如果他们告诉我们要做什么，我们就应该按照他们说的去做——如果我们不同意，我们需要正式表达我们的反对意见，并在GitHub问题上以学术严谨的态度进行讨论，而不是Stack Overflow的帖子认为有些东西是不必要的，因为你只是觉得不喜欢。我很抱歉直言不讳，但我希望你永远不要在安全关键的行业或部门工作，直到你的态度改变，因为我永远不想看到另一起Therac-25事件——这是由人们分享你对软件测试的态度直接引起的。

为什么我需要并被迫测试Redux实现，只要我可以测试显示的值，并且通过的测试将始终表明Redux实现在我的项目中正常工作？

因为您所描述的内容并不能提供接近完整代码覆盖范围的内容。

---

这里有一堆需要考虑的事情：

• 软件测试(以及任何领域的系统测试)通常可以归为以下几类：

  • 单元测试：测试单个"；单位"；与其他一切隔离的代码。
    • (旁注：许多人目前滥用xUnit和MSTest等单元测试框架来实现真正的集成测试，所以许多人不理解整合和单元测试之间的真正区别，这令人沮丧…)；单位"；将类似于单个class或function，而不是整个GUI应用程序
    • 您当前的测试策略不是单元测试，因为您没有孤立地测试任何东西：您必须启动整个应用程序，包括React/Redux管道、web服务器和，这是一个极其复杂、价值数十亿美元的GUI web浏览器程序应用程序
    • 一般来说：；如果您需要具体的依赖项(而不是fakes或mock)来测试某个东西，那么这不是一个单元测试，而是一个集成测试
  • 集成测试：测试相互作用的多个组件。
    • 这是一个相当抽象的定义，但它可能意味着在应用程序与生产数据库(副本！)耦合时测试应用程序的业务逻辑代码。这也可能包括在有GUI连接的情况下测试业务层，但GUI测试并不容易自动化——很多人(但不是所有人)不会将您正在做的事情视为单元测试，尤其是当您所描述的内容暗示您的测试不是在测试副作用或验证系统中其他地方(如数据库或后端web服务)的其他状态更改时
  • 除了单元和集成之外，还有其他类型的测试，但这两种测试是每个应用程序都应该拥有的全自动测试的主要类型，并且每个应用程序应该从单元测试和集成测试中获得良好的代码覆盖率。请注意，代码覆盖率并不意味着详尽无遗，如果代码包括琐碎的实现，如样板代码、参数验证代码或由经过良好测试的工具生成的代码，那么实现100%的代码覆盖率通常是浪费时间。
    • 一般来说：如果一段代码"是复杂的"；或者有规律地改变；"好"；(75%+？80%？90%？)代码覆盖率

• 因为通过GUI测试软件非常困难(而且很脆弱：因为GUI可能是任何面向用户的软件系统中经历重大变化最多的部分)，所以它实际上通常不会受到应有的自动化测试——这就是为什么通过自动化测试确保非GUI部分的良好覆盖很重要，这也减少了需要进行的手动GUI测试。

• 最后，对于Redux模式，需要特别考虑的一件大事是，Redux并不是GUI应用程序特有的。理论上，您应该能够将Redux应用程序复制并粘贴到服务器端Node.js JavaScript应用程序中，并将其连接到虚拟DOM，嘿，很快，您的应用程序就不再需要客户端JavaScript了！这也意味着，只需使用一个专门用于测试的虚拟DOM，而不是一个真正的浏览器DOM，就可以获得应用程序的良好代码覆盖率，但您目前的方法无法解决这一问题，因为您所说的只是验证对实际浏览器DOM的更改，而不是虚拟DOM。