unit-testing - 如果我已经实践了基于示例的测试，为什么还要真正使用基于属性的测试？

Question

一些开发人员对 TDD 与基于示例的测试争论不休的一个警告是，可能缺少每个有效的输入处理。

让我们举一个简单的例子，那些开发者可能会争论:

Make a program that add two numbers.

Bob，开发人员开始编写第一个测试:
给定 1 + 3，则结果为 4。
实现:def add(x: Int, y: Int) = 4
很好，它通过了。

现在第二次测试:
给定 2 + 2，则结果为 4。实现仍然相同:def add(x: Int, y: Int) = 4

所以其他开发人员会过来告诉他:

“现在你看到鲍勃，基于示例的测试对于你可怜的 2 个示例是不够的!
您没有测试每个输出并查看您的实际实现，对于结果不同于 4 的其他输入，它将失败!
现在，听我们说，开始编写一些基于属性的测试来覆盖所有有效输入。
因此，让我们从特定于加法的交换性测试、结合性等开始:加法的属性!”

但是但是但是....Bob的TDD实践真的很烂!
事实上，他想应用三角测量，但他编写了一个已经成功的测试，因为没有改变实现!

为了导致三角剖分，应该编写一个失败的测试。而三角剖分是TDD实践的万能 key 之一。
它允许主要步骤:重构，因为您应该管理导致 2 个不同结果的两条路径!

=> 只要测试变得具体，由于重构，代码就会变得更加通用。

所以我的问题是:
如果我们通过良好的三角测量实践来实践严格的 TDD，那么使用基于属性的测试、断言 99% 的案例中的不变量已经被良好的 TDD 覆盖的真正好处是什么？
事实上，假设开发人员具有良好的智商并构建有意义的实现；)

我的例子取自those slides .

Answer 1

当难以找到边缘案例或边缘案例太多以至于程序员很容易错过一个时，基于属性的测试非常有用。例如，我在实现 hirschberg 算法时使用了它。没有明显的方法可以将算法划分为更小、琐碎、易于 TDD 测试的部分。并且很难手工制作涵盖所有可能算法路径的输入。最好的方法是生成大量不同的输入以覆盖所有路径。当自动检查发现错误时，将该特定输入添加到回归测试中