问题标签 [property-based-testing]

我正在使用假设进行测试，并且我想在测试的两个参数之间建立关系。我知道assume，但是当我事先知道约束时，这似乎很浪费。

这是一个最小的例子：

上述统计摘要报告如下：

这是相当多的浪费尝试。这是一个非常简单的案例，但是在一个典型的数据量大的项目中，我可以预见很多这样的场景。所以我想知道，是否有一种简单的方法来判断两个参数满足某种关系的假设（在这种情况下，一个大于另一个）。我在文档中找不到任何内容。

I'm trying to generate a series of actions, where the actions that should be generated depend on what the previous actions were.

Let's say my state is a set of numbers stored as an array:

And there are the following actions:

I want to generate a series of actions to dispatch before checking properties of the state. If a remove action is generated, I want to ensure that it's value is in the state.

Valid Examples:

Invalid Examples:

Is this something that is possible using a property based testing library, and if so how would I accomplish it?

I am using https://github.com/dubzzz/fast-check, but if this is easier using another library I'm open to examples from others.

我想彻底测试两个BTreeSets 的交集的实现。我可以写：

但这具有较差的代码覆盖率，因为代码在某些情况下是专门的，随机集不太可能命中。一种特殊情况是元素范围几乎不相交的集合（一个集合的值 <= x，另一个集合的值 >= x）。在带有假设的 Python 中（我不是一个新手），我会写：

在 Rust 中，我只需要将所有内容都塞入体内：

如何将任意值的转换排除在测试用例主体之外？我无法理解我发现的有关策略的任何代码示例，而且 Stack Overflow 几乎没有与 proptest 相关的问题。

我正在使用Scalatest 3.1.0-SNAP13并且找不到如何从此PR指定 init 种子选项。我正在使用 SBT 运行测试，因此如果有办法指定此选项build.sbt将是理想的。

我是 Hypothesis 的新手，我想测试一个从 Hypothesis Strategy 获取整数输入的函数：

假设测试从 min_value 2 到 9 的函数。

有没有办法可以扭转这种情况？我希望测试用例以 t=9 而不是 t=2 开始。

我想在文件中的示例数据集上运行 scalacheck。如何创建一个从该文件读取数据并允许我检查其属性的生成器？

假设我有两个实现相同基本 API 的类，并且我想测试它们是否是“随机等效的” ¹，至少在它们的方法的一个子集上。

例如，我编写了自己的“列表”类foo:list，而不是煞费苦心地为它编写一堆单元测试，我想将其std::list作为参考进行比较。也就是说，对 的任何操作序列都foo::list应该产生与 的相同序列相同的结果std::list。

我可以列出操作的名称，但希望不会比这更多的样板。可以应用于其他“行为等效”类对的通用解决方案是理想的。

¹ “随机等价”是指在许多系列操作中没有观察到差异，这显然没有完全证明等价。

我在 Kotlin 中有以下有向图的定义。（我还在学习 Kotlin，所以请原谅任何缺点。总是欢迎改进和建议。）我的目标是有一个方法，reverse它保持顶点和循环，但交换其他边的方向。

我想使用基于属性的测试来使用 KotinTest 测试此代码，但我在构建它以正确生成无向图的随机样本时遇到了麻烦。如果我能做到这一点，我可以将边缘方向反转两次，然后确保实现原始图形。

我熟悉Gen.list,Gen.choose等，但我似乎无法将这些部分组合在一起以获得最终产品，即随机无向图。

我已经完成了这一点，但这显然缺少部分，我希望有人能够提供帮助。我怀疑我可以在 Scala 中做到这一点，因为我在那里有更多的经验，但我决心学习 Kotlin。最终，大致如下：

任何帮助/建议将不胜感激。谢谢！

假设允许两种不同的方式来定义派生策略，@composite并且flatmap。据我所知，前者可以做后者可以做的任何事情。但是，numpy策略的实施arrays，讲了一些隐性成本

我认为这意味着更糟糕的收缩行为，但我不确定，我在其他任何地方都找不到这个记录。那么我应该什么时候使用@composite，什么flatmap时候应该像上面链接的实现那样走这条中途路线？

在基于属性的测试设置中，例如 Haskell 对自定义数据结构的快速检查，您如何为关系的 n 元属性（例如传递性或对称性）生成测试数据？我认为，实现语言无关紧要。

这是一个使用rapidcheck的幼稚 C++ 示例（只是因为我现在手头有这个工具）：

在这种幼稚的情况下，该工具不太可能生成许多前提 ( a == b) 实际成立的示例，因此您最终会在无意义的测试上浪费大量精力。对于像传递性这样的三元关系，情况会变得更糟。

是否有解决这些问题的通用技术？我是否需要生成相等的对（对于“等于”的一些建设性定义）？订单之类的东西呢？