我正在学习 FP，并了解了基于属性的测试的概念，对于来自 OOP 世界的人来说，PBT 看起来既有用又危险。它确实检查了很多选项，但是如果有一个（或一些）选项失败了，但在您的第一个假设 Jenkins 构建期间它们没有失败，该怎么办。那么下次运行构建时，测试可能会失败，也可能不会失败，这是否会扼杀可重复构建的整个想法？
我看到有些人explored options to make the tests deterministic，但是如果这样的测试没有捕捉到错误，它就永远不会捕捉到它。
那么这里有什么更好的方法呢？我们是牺牲构建的可重复性来最终发现错误，还是冒着从未发现错误的风险，但又恢复了可重复性？
（我希望我正确理解了 PBT 的概念，但如果我没有理解，如果有人能指出我的误解，我将不胜感激）
做了很多基于属性的测试，我不认为不确定性是一个大问题。我基本上经历了三种类型：
属性实际上是不确定的 b/c 某些外部因素 - 例如超时，延迟，数据库配置 - 让它如此。那些不稳定的测试也出现在基于示例的测试中，应该通过使外部因素具有确定性来消除。
一个属性很少失败，因为触发条件只是有时通过伪随机数据生成来满足。大多数 PBT 库都有重现那些失败运行的方法，例如通过重新使用失败测试运行的随机种子，甚至记住某种数据库中的确切星座。这些失败揭示了问题，这也是我们首先进行随机测试用例生成的原因之一。
覆盖断言（“在所有情况下至少有 5% 会出现这种情况”）有时可能会失败，即使它们通常是正确的。这可以通过增加尝试次数来缓解。一些库，例如 quickcheck，自己计算需要多少次尝试来证明/反驳覆盖率假设，从而主要消除那些误报。
重要的是始终跟进片状失败并找到错误、不确定的外部因素或属性不变量中的错误假设。当您这样做时，零星故障将越来越少发生。我的个人经历主要是使用 jqwik，但其他人也告诉过我类似的故事。