为什么我需要测试 Redux 实现，而我只能使用测试库测试 DOM？
Why do I need to test Redux implementations while I can just test the DOM using a testing library?
我看不懂测试的全过程。我正在使用一个测试库，我觉得只测试文本、标签很舒服，我觉得我不需要测试 React 中的任何实现，或者 Redux, and this is what I read in the React testing library documentation, as Enzyme 强迫人们总是测试 React 实现。
现在如果所有文本、标签和显示值在我的测试中都是正确的，这意味着一切都应该没问题，但不幸的是，当我使用 Redux 时，我总是被迫测试 Redux 实现（模拟存储、模拟 reducer 等）和 异步行为 如获取数据等。
为什么我需要并且被迫测试 Redux 实现，只要我可以测试显示的值，通过的测试将始终表明 Redux 实现在我的项目中正常工作？
I can't understand the full process of testing
这是可以理解的。测试和软件质量保证是一个巨大的专业领域（比视频游戏测试更重要！）
I am using a testing library and I feel comfortable with testing just texts, labels and I feel I don't need to test any implementation in React or Redux
这是错误的态度。您所描述的是非常 non-rigorous、草率、随意 - 最重要的是：浅层测试。
仅仅因为用户计算机屏幕上的数据看起来正确，并不意味着它实际上是正确的。你怎么知道你实际上没有与模拟的 UI 交互，或者后端数据库实际上包含新数据？或者没有任何负面影响（例如系统 删除所有其他内容 - 是的，这发生在我身上一次......）。
打个比方，你是说你很乐意乘坐一架经过测试的飞机，只要确保 the control yoke resulted in the on-screen airplane icon 向正确的方向移动——即使飞机仍然稳稳地在地面。我不想坐那架飞机。
Now if all texts, labels, displayed values all are true in my tests, this means that everything should be OK
不，不是。见上文。
but unfortunately when I am using Redux, I always forced to test Redux implementations (mocking the store, mocking reducers, etc.) and async behaviors like fetching data and so on.
是的。您被迫 做正确的事 。它被称为 the Pit of Success. Don't fight it. It's for the best. These libraries, platforms and frameworks are designed by people with more experience in software design than both of us, so if they tell us to do something we should do what they say - if we disagree we need to formalize our objections and duke it out in GitHub issues with academic rigour, not Stack Overflow posts arguing that something's unnecessary because you just don't feel like it. With apologies for being blunt, but I hope you never work in a safety-critical industry or sector until your attitude changes because I never want to see another Therac-25 incident - 这是由人们分享您对软件测试的态度直接造成的。
Why do I need and am forced to test Redux implementations as long as I can just test displayed values and passed tests will always indicate that Redux implementations work correctly in my project?
因为您所描述的内容并未提供接近 full code-coverage 的任何地方。
这里有一堆需要考虑的事项：
软件测试（以及任何领域的一般系统测试）通常可以归为以下几类：
- 单元测试：独立于其他所有内容测试代码的单个“单元”。
- (Side-note：许多人目前正在滥用 unit-testing 框架，如 xUnit and MSTest 来实现实际上是 集成测试 ，所以很多人不明白 integration 和单元测试的真正区别，郁闷...）。 “单元”类似于 单个
class 或 function，而不是整个 GUI 应用程序。
- 您当前的测试策略不是单元测试，因为您没有孤立地测试任何东西：您必须 fire-up 整个应用程序，包括 React/Redux 管道，web-server 和一个极其复杂的multi-billion-dollarGUIweb-browser程序应用程序。
- 一般来说：“如果您需要具体的依赖项（而不是假货或模拟）来测试某些东西，那不是 unit-test，而是 integration-test”。
- 集成测试：测试相互交互的多个组件。
- 这是一个相当抽象的定义 - 但它可能意味着当应用程序的业务逻辑代码与生产数据库的（副本！）耦合时测试它。这还可以包括在附加了 GUI 时测试 business-layer，但是 GUI 测试不容易自动化 - 很多人不会考虑你的东西，但不是全部作为 unit-test，尤其是正如您所描述的那样，您的测试不是针对 side-effects 进行测试，也不是在验证系统其他地方（例如数据库或后端）的其他状态更改web-service).
- 除了 unit 和 integration 之外，还有其他类型的测试 - 但这两种是 fully 的主要类型每个应用程序都应该有的自动化测试——每个应用程序都应该有良好的code-coverage，尤其是单元测试和集成测试。请注意 code-coverage 并不意味着详尽无遗，如果该代码包含 琐碎的实现 样板代码或参数，那么实现 100% code-coverage 通常是浪费时间验证代码，或由本身经过 very-well 测试的工具生成的代码。
- 一般来说：如果一段代码“复杂”或有规律地变化，它应该有“好”（75%+？80%？90%？）code-coverage.
因为通过 GUIs 测试软件非常困难（而且很脆弱：因为 GUIs 可能是任何 user-facing 软件系统）它实际上通常不会像它应该的那样在任何地方进行自动化测试 - 这就是为什么通过自动化测试确保良好覆盖 non-GUI 部分很重要，这也减少了手动 GUI 需要做的测试。
最后，对于 Redux 模式特别需要考虑的一件大事是 Redux 并不特定于 GUI 应用程序。从理论上讲，您应该能够获取 Redux 应用程序并将其复制并粘贴到 server-side Node.js JavaScript 应用程序并将其连接到虚拟 DOM 和 hey-presto，您的应用程序不再需要 client-side JavaScript 才能工作！这也意味着您可以通过使用用于测试的特殊虚拟 DOM 而不是真正的浏览器 DOM 来获得出色的 code-coverage 应用程序 - 但您当前的方法不适用于此因为你在说仅验证对真实浏览器 DOM 的更改，而不是虚拟 DOM.
我看不懂测试的全过程。我正在使用一个测试库，我觉得只测试文本、标签很舒服，我觉得我不需要测试 React 中的任何实现，或者 Redux, and this is what I read in the React testing library documentation, as Enzyme 强迫人们总是测试 React 实现。
现在如果所有文本、标签和显示值在我的测试中都是正确的，这意味着一切都应该没问题，但不幸的是，当我使用 Redux 时，我总是被迫测试 Redux 实现（模拟存储、模拟 reducer 等）和 异步行为 如获取数据等。
为什么我需要并且被迫测试 Redux 实现，只要我可以测试显示的值，通过的测试将始终表明 Redux 实现在我的项目中正常工作？
I can't understand the full process of testing
这是可以理解的。测试和软件质量保证是一个巨大的专业领域（比视频游戏测试更重要！）
I am using a testing library and I feel comfortable with testing just texts, labels and I feel I don't need to test any implementation in React or Redux
这是错误的态度。您所描述的是非常 non-rigorous、草率、随意 - 最重要的是：浅层测试。
仅仅因为用户计算机屏幕上的数据看起来正确，并不意味着它实际上是正确的。你怎么知道你实际上没有与模拟的 UI 交互，或者后端数据库实际上包含新数据？或者没有任何负面影响（例如系统 删除所有其他内容 - 是的，这发生在我身上一次......）。
打个比方，你是说你很乐意乘坐一架经过测试的飞机，只要确保 the control yoke resulted in the on-screen airplane icon 向正确的方向移动——即使飞机仍然稳稳地在地面。我不想坐那架飞机。
Now if all texts, labels, displayed values all are true in my tests, this means that everything should be OK
不，不是。见上文。
but unfortunately when I am using Redux, I always forced to test Redux implementations (mocking the store, mocking reducers, etc.) and async behaviors like fetching data and so on.
是的。您被迫 做正确的事 。它被称为 the Pit of Success. Don't fight it. It's for the best. These libraries, platforms and frameworks are designed by people with more experience in software design than both of us, so if they tell us to do something we should do what they say - if we disagree we need to formalize our objections and duke it out in GitHub issues with academic rigour, not Stack Overflow posts arguing that something's unnecessary because you just don't feel like it. With apologies for being blunt, but I hope you never work in a safety-critical industry or sector until your attitude changes because I never want to see another Therac-25 incident - 这是由人们分享您对软件测试的态度直接造成的。
Why do I need and am forced to test Redux implementations as long as I can just test displayed values and passed tests will always indicate that Redux implementations work correctly in my project?
因为您所描述的内容并未提供接近 full code-coverage 的任何地方。
这里有一堆需要考虑的事项：
软件测试（以及任何领域的一般系统测试）通常可以归为以下几类：
- 单元测试：独立于其他所有内容测试代码的单个“单元”。
- (Side-note：许多人目前正在滥用 unit-testing 框架，如 xUnit and MSTest 来实现实际上是 集成测试 ，所以很多人不明白 integration 和单元测试的真正区别，郁闷...）。 “单元”类似于 单个
class或function，而不是整个 GUI 应用程序。 - 您当前的测试策略不是单元测试，因为您没有孤立地测试任何东西：您必须 fire-up 整个应用程序，包括 React/Redux 管道，web-server 和一个极其复杂的multi-billion-dollarGUIweb-browser程序应用程序。
- 一般来说：“如果您需要具体的依赖项（而不是假货或模拟）来测试某些东西，那不是 unit-test，而是 integration-test”。
- (Side-note：许多人目前正在滥用 unit-testing 框架，如 xUnit and MSTest 来实现实际上是 集成测试 ，所以很多人不明白 integration 和单元测试的真正区别，郁闷...）。 “单元”类似于 单个
- 集成测试：测试相互交互的多个组件。
- 这是一个相当抽象的定义 - 但它可能意味着当应用程序的业务逻辑代码与生产数据库的（副本！）耦合时测试它。这还可以包括在附加了 GUI 时测试 business-layer，但是 GUI 测试不容易自动化 - 很多人不会考虑你的东西，但不是全部作为 unit-test，尤其是正如您所描述的那样，您的测试不是针对 side-effects 进行测试，也不是在验证系统其他地方（例如数据库或后端）的其他状态更改web-service).
- 除了 unit 和 integration 之外，还有其他类型的测试 - 但这两种是 fully 的主要类型每个应用程序都应该有的自动化测试——每个应用程序都应该有良好的code-coverage，尤其是单元测试和集成测试。请注意 code-coverage 并不意味着详尽无遗，如果该代码包含 琐碎的实现 样板代码或参数，那么实现 100% code-coverage 通常是浪费时间验证代码，或由本身经过 very-well 测试的工具生成的代码。
- 一般来说：如果一段代码“复杂”或有规律地变化，它应该有“好”（75%+？80%？90%？）code-coverage.
- 单元测试：独立于其他所有内容测试代码的单个“单元”。
因为通过 GUIs 测试软件非常困难（而且很脆弱：因为 GUIs 可能是任何 user-facing 软件系统）它实际上通常不会像它应该的那样在任何地方进行自动化测试 - 这就是为什么通过自动化测试确保良好覆盖 non-GUI 部分很重要，这也减少了手动 GUI 需要做的测试。
最后，对于 Redux 模式特别需要考虑的一件大事是 Redux 并不特定于 GUI 应用程序。从理论上讲，您应该能够获取 Redux 应用程序并将其复制并粘贴到 server-side Node.js JavaScript 应用程序并将其连接到虚拟 DOM 和 hey-presto，您的应用程序不再需要 client-side JavaScript 才能工作！这也意味着您可以通过使用用于测试的特殊虚拟 DOM 而不是真正的浏览器 DOM 来获得出色的 code-coverage 应用程序 - 但您当前的方法不适用于此因为你在说仅验证对真实浏览器 DOM 的更改，而不是虚拟 DOM.