问自动化测试无益的场景？

EN

我认为迈克尔总结得非常好：“那些无法真正正式指明的事情”。事实证明，有很多事情无法正式指定。可用性是一个例子（虽然一旦你决定哪种行为可用，你当然可以并且当然应该测试那种行为！）。有点矛盾的是，许多数字训练任务无法正式指定：例如天气预报。目标当然是预测明天的天气，但这不是正式的规范。因此，你可以测试你使用的算法是否做了他们应该做的事情（计算平均值，反转矩阵，可以正式指定的东西），但是你的天气预报程序可以通过所有测试，但仍有90％的时间是错误的。或者你可以使用大量的历史数据来测试算法是否能产生良好的预测，但这很危险，因为它很容易导致算法只对你使用的历史数据准确，而不是一般。这可能意味着您的单元测试需要数小时或数天才能运行。更糟糕的是，您的算法可能具有必须“调整”的参数，例如对于所使用的测量仪器，并且每个算法的最佳参数可能不同，因此单元测试需要手动交互以找到好的参数。在理论上可能，但可能不是很有用。我猜相同的论点将适用于OCR，ICR，许多信号处理任务，人脸识别（以及许多其他图像处理任务），典型的Photoshop工具，如“红眼消除”，

我坚信有思想的测试; 但是，我觉得单元测试和TDD主要是浪费时间。

从实证的角度来看：

1. 没有经验证据证明代码质量更高。
2. 没有经验证据表明生产率更高。
3. 没有经验证据证明可以节省成本。
4. 以伪科学方式呈现的“故事”表明TDD是有益的，但没有控制组，也没有真正的指标。

TDD的好处：

1. 通过提升专业知识，“了解”TDD的福音传道者。
2. 销售/推广单元测试工具的软件组受益。
3. 如果您的开发人员不是高素质的，那么单元测试可能会有一些好处。
   • 单元测试仅捕获最明显的错误
   • 如果开发人员通过单元测试始终发现错误，我会替换它们。
   • 如果我将开发外包给班加罗尔的车身车间，我会实施单元测试。否则，我会坚持与强大的开发人员合作 - 从长远来看，这些人更具成本效益。

主观分析：

1. 如果您听取TDD支持者提出的论点，您可以随时用祈祷取代TDD，并且推理的有效性不会改变......
2. 单元测试是代码 - 您将代码库的大小增加一倍/三倍......分析代码可能会花费更多时间。
3. 高质量的软件来自对抗/合作团队。编写代码的同一实体没有业务测试代码 - 这应该是QA分析师的工作。
4. 高质量和高性价比的软件来自以下良好的设计原则 - SOLID / GRASP / GoF
5. 在审查单元测试和TDD之后，我想要的真实世界类比是...它有点像在自己上面运行一个检查清单，例如：
   • 吸气检查
   • 呼气检查
   • 左脚向前检查
   • 右脚向前检查
   • 眨眼睛检查
   • 插入口香糖检查
   • 闭嘴检查
   • 张开嘴检查
   • 迭代直到燕子检查......
   • 是的，你实际上可能会发现一个问题，但如果不花费大量精力为它编码，你将永远不会发现任何后果。

6. 杰布斯告诉我，TDD是假神。