自动化测试无益的场景

Question

在某些情况下，单元测试和TDD等比它们的价值更麻烦？

我想出的一些事情是：

• 生成测试数据时很棘手：有时，能够提出有效的，非平凡的测试数据本身就是一个挑战。
• 验证代码正确性的唯一实用方法是运行它。
• 当您测试设计的视觉元素时。

还有什么其他案例？

Answer 1

我相信你的前两点无效。

• 创建测试数据可能是一个挑战（事实上，它通常是编写单元测试的主要部分），但这只是你必须接受的东西，而不是放弃单元测试的理由。并且这不是不可能的，否则你怎么知道你的应用程序是否正常工作？
• 单元测试运行代码以验证其正确性 - 我没有看到问题。

当然，应用程序的方面无法经过单元测试 - 可视化布局（屏幕或打印）就是这样一个方面，一般的可用性 - 无法真正正式指定的东西。

单元测试可能不适用的情况是，当您面对的是现有的应用程序时，无法考虑可测试性或模块化（Big Ball of Mud反模式）。但即便如此，如果你知道你必须在相当长的一段时间内维护和扩展这种野兽，那么找到一种方法来自动测试应用程序的至少某些部分几乎总是可行和有用的。没有人说你必须编写一个测试套件，在做任何其他事情之前可以实现100％的代码覆盖率。

Answer 2

我不确定它是否无益。在某些情况下，它可能会更加困难，您可能会选择不使用它 - 例如，在UI的可视布局中。有时可能会浪费精力 - 例如，单元测试设计器生成的代码或框架，而不是由您编写的。生成数据不应成为单元测试的障碍。您的测试应该足够小并且足够集中，以至于您通常不需要为任何单个测试生成整个数据集，因此在这些情况下，模拟是非常有用的技术。如果我发现自己一遍又一遍地嘲笑同样的事情，我有时会把它合并成一个假的数据库类，所有的测试都可以依赖它。

单元测试和运行代码都不会验证其正确性。单元测试可以帮助消除错误，特别是使用TDD，并确保找到的错误是固定的。如果您需要确保代码正确，则需要应用不同的基于逻辑的技术来证明正确性。这些超出了单元测试的范围。

Answer 3

我不会说有任何自动化测试无益的情况。

肯定会有一些不太有帮助的地方。我认为创建夹具数据不是其中之一。有一些工具可以帮助，比如factory_girl（至少在Ruby中）。事实上，如果你的模型非常复杂，你需要创建十几个具有各种关联的对象，我会考虑代码的味道，也许模型不是那么简洁。

尽管如此，有几个案例的缺点可能超过了好处。前几天我写了一些代码，要求外部进程。我不关心输出，我不关心返回代码，我甚至不关心它是否工作正常，它完全是火和忘记，如果某些东西不能正常工作，另一个过程将会清理干净，后面。

在这种情况下，我没有费心去编写任何测试，因为设置虚假的外部程序来验证我的论据等等，这样做的好处并不值得。

Answer 4

对此有一些随意的想法：

1. 我认为微软没有 单元测试它的各种方式 关闭电脑。可能 完成虚拟，但它是 可能不值得
2. 对于硬件制造商：确保驱动程序适用于不同的硬件 可能也是手动完成的（嗨 有nvidia，你打破了我的gfx卡 ;））
3. 一次运行shell脚本。只需调整它们直到它们正常工作

但这些仍然是个案。我也认为它们几乎总是可行的，从长远来看通常会比你在开始时投入更多的回报。

Answer 5

* When generating test data is tricky: Sometimes, being able to come up with valid, non trivial test data is a challenge in itself.

当您需要系统与“完整数据集”处于“上下文”时，您所做的不是单元测试。它正在测试，但你对“单位”的压力很大。您需要进行较小的测试。 TDD的难点在于使您的代码处于这样的形状，您可以在小型中对其进行测试。这很有价值，但并不容易。如果你进行test-after（非TDD），那么几乎不可能避免你的情况。

因此，当你想测试大于单位的东西（即类中的方法）时，你会想要使用像UAT之类的东西。但在这种情况下，您仍然需要像练习TDD一样对各个函数进行测试。

* When the only practical way of verifying correctness of the code is to run it.

但代码 在单元测试中运行。你的意思是什么时候在或其他什么地方运行？

* When you're testing visual elements of the design.

我认为这是你的第二个要点，但我猜不是。尝试在UT中测试布局很难并且通常都没有用。这样的测试很脆弱。

因此，在某些情况下使用UT进行大型子系统测试或验证屏幕布局可能没有用。但即便如此，对于仍然有90％的工作来说，这是非常有价值的。

Answer 6

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

Answer 7

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

从经验的角度来看：

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

TDD的好处：

1. 通过提升专业知识来“了解”TDD的福音传道者。
2. 销售/推广单元测试工具的软件组受益。

3. 如果您的开发人员不是高素质的话，单元测试可能会有一些好处。

   • 单元测试仅捕获最明显的错误
   • 如果开发人员通过单元测试始终发现错误，我会替换它们。
   • 如果我将开发外包给班加罗尔的车身车间，我会实施单元测试。否则，我会坚持与强大的开发人员合作 - 从长远来看，这些人更具成本效益。

主观分析：

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