我将在单元测试方面做一个演示，并且这样做我将触及“可测试性设计”模式。换句话说，使用IOC容器，依赖注入，避免静态方法等。
我有一种感觉，我的团队会冷静地开始编码以适应测试。所以我想知道是否有人知道任何真实世界的例子，无其他理由改变某种设计，然后更容易测试。
我假设这个概念在制造业，工程学和其他专业中并不少见，我只是不熟悉任何难以理解的例子。
我想象土星五号火箭，航天飞机，汽车，机器人等的发展必须有一些记录的可测试性设计的例子，或者可能缺乏导致问题的设计。
想到的例子
答案 0 :(得分：1)
许多电涌保护器都有一个测试按钮来检查正确的功能。这是一种非常聪明的测试形式，因为它不仅掌握在开发人员手中，而且掌握在最终用户手中。
另一个例子：许多控制报告灯（特别是在关键环境中，如核电站等）有一个按钮可以打开它们并检查它们是否仍然可以正常工作。许多使用LED显示屏的电器都是如此。
电池有电源指示灯，因此您可以在购买前进行测试。
在糖精制中，您可以监控生产的许多步骤（断点类型）以评估产品的质量。该工厂的设计旨在提供这些测试断点，以便人类采样器轻松访问（通常收费不高）。
最后，汽车制造商包括各种诊断。汽车维修店有一台电脑，可以全面检查汽车的状态。它是一种“事后”调试日志，所以不是真正的“预防性测试”，但仍然非常有用，并且包含它是一个真实世界的“可测试性设计”。
然而，实际测试和软件世界测试之间的主要区别在于，真实世界的测试可能会毁坏产品，达到破坏性的极限。因此，通过破坏性采样和分析评估故障 - 良好比率。在软件测试中，你永远不会进行破坏性测试（除非你是一个有邪恶意图的虐待狂程序员）答案 1 :(得分：0)
如果已经构建了一组组件以便对它们进行测试，那么它们可能会更加模块化并且松散耦合。例如，测试使用IOC容器而不是服务定位器的代码更容易，因为可以简单地模拟和注入协作者。
这种分离随后进入发展阶段。由于该类型对其协作者没有硬依赖性，因此它允许以不同的结构组合这些部分，这意味着重构/响应新需求更简单。您还可以对任何重构更有信心，因为您有一套测试来验证您的更改。
总之，根据我的经验，这意味着为测试而编写的代码更快更容易修改，这导致我的工作量减少，我喜欢。
设计用于测试（自身或其他事物）的组件的一些真实世界示例，以避免更大的问题：