问题标签 [property-based-testing]

故事：

目前，我有一个被测函数，它需要一个具有以下规则的整数列表列表：

1. 子列表的数量（我们称之为N）可以从 1 到 50
2. 子列表中的值的数量对于所有子列表（矩形形式）都是相同的，并且应该 >= 0 和 <= 5
3. 子列表中的值不能大于或等于子列表的总数。换句话说，子列表中的每个值都是一个整数 >= 0 并且 <N

样本有效输入：

示例无效输入：

我正在尝试使用基于属性的测试来处理它，并使用hypothesis库生成不同的有效输入，并试图将我的头绕在lists()andintegers()上，但无法使其工作：

• 条件 #1 很容易用lists()andmin_size和max_size参数处理
• 条件 #2 涵盖在Chaining strategies together
• 条件 #3 是我正在努力解决的问题 - 因为，如果我们使用rectangle_lists上面示例中的，我们没有对内部“父”列表长度的引用integers()

问题：

如何将子列表中的整数值限制为小于子列表的总数？

我的一些尝试：

这远远不能满足要求 - 列表不是严格的矩形形式，并且生成的整数值可以超过列表的生成大小。

在这里，#1 和 #2 是满足要求，但整数值可以大于列表的大小 - 不满足要求 #3。

故事：

我目前正在使用hypothesis和自定义生成策略对函数进行单元测试，试图找到一个特定的输入来“破坏”我当前的解决方案。这是我的测试的样子：

answer()基本上，当函数不返回 0 或 1 或 2时，我正在寻找可能的输入。

这是我当前的工作流程的样子：

• 运行测试

• hypothesis找到一个产生 的输入AssertionError：

  /li>

• 使用此特定输入调试函数，尝试了解此输入/输出是否合法并且该函数是否正常工作

问题：

我怎样才能跳过这个伪造的生成示例（[[0], [1]]在这种情况下）并要求hypothesis生成一个不同的示例？

该问题也可以解释为：hypothesis如果发现伪造示例，我可以要求不终止并生成更多伪造示例吗？

我在一个文件中有一组名称。我需要实现一个不断迭代它们的生成器。但是，代码if (iter.hasNext)在第一次通过后会无限期地挂起。

生成代码

样品性能测试

en_US_sample.txt 文件内容

编辑-临时工作代码

如果我重新创建迭代器，以下代码可以工作，但我想知道为什么Iterator.continually会挂起？

我们的案例类有几个require语句可以在收到格式错误的输入时抛出异常。这通常很有帮助，但会使编写基于属性的测试变得痛苦，因为我们必须编写满足所有要求的生成器，而不是简单地使用内置的生成器。有没有一种简单的方法可以让 Scala 在测试期间忽略 require 语句？

我认为是时候尝试 FsCheck 了，但事实证明它比我想象的要难。有很多关于Arb, generators 等的文档，但似乎没有任何关于如何应用这些知识的指导。或者我只是不明白。

可能更难理解的是，测试、属性、生成器、任意性、收缩以及在我的情况下随机性（一些测试自动生成随机数据，其他测试不会）之间的关系对我来说并不清楚。我没有 Haskell 背景，所以这也无济于事。

现在的问题是：如何生成随机整数？

我的测试场景可以用乘法的性质来解释，比如说分布性：

当我使用Check.VerboseNUnit 集成运行它时，我得到如下测试序列：

经过1000次测试，它还没有结束100L。不知何故，我想象这将“自动”选择均匀分布在整个范围内的随机数int64，至少我是这样解释文档的。

既然没有，我开始尝试并想出如下愚蠢的解决方案来获得更高的数字：

但这变得异常缓慢，显然不是正确的方法。我确信必须有一个我缺少的简单解决方案。我试过了Gen.choose(Int64.MinValue, Int64.MaxValue)，但这只支持整数，而不是长整数（但即使只有整数我也无法让它工作）。

最后，我需要一个适用于所有原始数值数据类型的解决方案，包括它们的最大值和最小值、它们的零和一，以及从其中的任何内容中进行的一些随机选择。

如何基于属性测试采用函数列表的函数？

采取以下功能：

附加上下文如下：

我尝试了以下测试，然后意识到我的预定义函数都没有被使用（显然），因为在运行时生成了任意函数​​：

例子：

我的属性测试如下：

handleAll函数是基于属性的可测试的吗？

我们正在寻找一种可行的设计模式来构建Gen可以产生正面和负面测试场景的 Scalacheck（生成器）。这将允许我们运行测试来验证功能（正面案例），并通过在所有无效数据组合上forAll失败来验证我们的案例类验证是否正常工作。

制作一个简单的、参数化Gen的一次性完成此操作非常容易。例如：

通过以上，我可以得到一个有效或无效的 ID 用于测试目的。有效的，我用来确保业务逻辑成功。无效的，我用来确保我们的验证逻辑拒绝案例类。

好的，所以 - 问题是，在很大程度上，这变得非常笨拙。假设我有一个包含 100 个不同元素的数据容器。生成一个“好”的很容易。但是现在，我想生成一个“坏”的，此外：

1. 我想为每个数据元素生成一个错误的数据元素，其中单个数据元素是错误的（因此至少有 100 个错误实例，测试每个无效参数是否被验证逻辑捕获）。

2. 我希望能够覆盖特定元素，例如输入错误的 ID 或错误的“foobar”。不管那是什么。

我们可以寻找灵感的一种模式是applyand copy，它允许我们在指定覆盖值的同时轻松组合新对象。例如：

上面我们看到了从另一个对象的模板创建变异对象的基本思想。这在 Scala 中更容易表达为：

以此为灵感，我们可以思考我们的目标。有几点需要考虑：

1. 首先，我们可以为数据元素和生成的值定义一个映射或键/值容器。这可以用来代替元组来支持命名值突变。

2. 给定一个键/值对容器，我们可以轻松地随机选择一个（或多个）对并更改一个值。这支持生成一个数据集的目标，其中一个值被更改以产生故障。

3. 给定这样一个容器，我们可以轻松地从无效的值集合中创建一个新对象（使用其中一种apply()或其他技术）。

4. 或者，也许我们可以开发一种使用元组然后只使用apply()它的模式，有点像copy方法，只要我们仍然可以随机更改一个或多个值。

我们或许可以探索开发一种可重复使用的模式，它可以执行以下操作：

在上面的代码中，我们有一个thingGen返回 (valid)的生成器Things。然后对于返回的所有实例，我们调用一个通用方法invalidate(count: Int)，该方法将随机使count值无效，返回一个无效对象。然后我们可以使用它来确定我们的验证逻辑是否正常工作。

这将需要定义一个invalidate()函数，给定一个参数（按名称或按位置），然后可以将识别的参数替换为已知错误的值。这意味着对特定值有一个“反生成器”，例如，如果一个 ID 必须是 3 个字符，那么它知道创建一个长度不超过 3 个字符的字符串。

当然，要使已知的单个参数无效（将不良数据注入测试条件），我们可以简单地使用复制方法：

这是我迄今为止的想法的总和。我在吠叫错误的树吗？是否有处理这种测试的好模式？关于如何最好地解决这个测试我们的验证逻辑的问题的任何评论或建议？

我正在阅读 Kent Beck 的“示例测试驱动开发”一书（此处提供 pdf 文件），其中他讨论了多币种货币问题并逐步设计了一个解决方案，通过引入测试并因此指定其公共方法类和反复重构以适应新的测试/行为。

他从上课Franc开始。Dollar然后考虑了这些类的接口并查看了代码并发现了重复，他将这两个类重构为都派生自一个Money类。

几次测试之后，他意识到类Franc并Dollar没有真正的意义，并currency为货币引入了一个字符串，最后当它需要对不同货币的货币求和时，他提出了一个Money名为的类的超类，expression它简化了对对 Money 的附加操作，例如对不同货币求和。

综上所述，在我的理解中，指导 TDD 设计过程的是对象的行为和测试期望。我的问题是，由于函数式编程较少关注对象并且更多地面向类型类/特征，这是否意味着这种测试驱动的设计实践并不真正适合函数式风格？是否可以认为属性驱动的测试在设计过程中与功能风格发挥类似的作用？

编辑：

在基于属性的测试中，人们会为方法引入属性，无论给定方法的实现如何，这些属性都应该保持不变。在正常测试中，被验证的最重要的属性是实现的正确性。正如 sisyphus指出的那样，存在断言论点的先验知识从何而来的问题，因此检查正确性并不一定能给我们提供全貌。

还有其他注意它们的属性，可能会很有启发性。例如，如果我要编写一个排序函数并拥有sortedList=mySort(myList)，无论实现如何，我都希望sortedList和myList具有相同的长度。如果不是这样，我可能做错了什么，即使测试可能对所有其他情况都有效。

另一个例子，一个MaxElement(list)返回Option[int]整数列表作为输入的函数，如果list不为空，则应该总是返回 Some[int]。

要检查这些属性，可以为这些方法的输入编写一个定制的生成器，然后要求测试框架生成足够的输入实例并测试属性以保证其有效性几乎可以确定。例如，在货币问题的情况下，可以编写一个生成器来生成各种类型的货币子类并检查它们的相等性，这将自动揭示出考虑贝克明确编写的一些相等性测试的必要性.

重新表述这个问题，我很想知道他是否犯了一个自然错误的原因，即明确的类Franc和Dollar- 他后来意识到，当他注意到两个类中某些方法的重复实现时 - 与面向对象方法密切相关在建模系统中。是否可以说函数式编程不需要这种迭代设计过程，仅仅是因为它不是从对象开始，而是进行函数分解。或者从另一个角度来看问题，测试是否会导致功能风格上的系统设计改变？

我正在尝试将 ScalaTest 与 ScalaCheck 一起使用来进行基于属性的测试。我有下面列出的测试：

现在我看到的是，如果我一遍又一遍地在 PropSpec1 中运行测试，有时第二个测试会通过，但大多数时候它会失败。现在，如果 0 没有针对 b 进行测试，那么显然它会通过，但我认为这是它总是会尝试的事情之一。重复运行 sbt clean test 时，我看到了相同的行为；有时两个测试都通过。

这对于基于属性的测试是正常的，还是我需要做一些事情（比如总是提供我自己的生成器）？

延迟生成器可能对递归数据结构有意义。我想知道这在哪种情况下Prop.delay会有所帮助。能否请您演示一个现实生活中的例子。