基于属性的测试：框架抽象边界与生成属性融合难题
【导语：本文围绕基于属性的测试（PBT）展开，探讨了其属性与生成器的关系，指出在实际应用中两者并非相互独立，还分析了不同 PBT 框架在处理抽象边界时的表现及存在的问题。】
在基于属性的测试（PBT）中，属性是一种全称量化的计算，必须对所有可能的输入都成立，在编程语言中，最简单的模型是一个返回布尔值的函数。例如 `\l -> reverse (reverse l) == l` 断言对列表进行两次反转后会得到原始列表。当涉及前置条件时，情况会更复杂，如 `prop_insert_select` 函数，需检查数据库中是否存在指定的表。
除了属性，还需要为其准备随机生成器。可以为所有输入类型编写 `Arbitrary` 实例，但简单随机生成可能导致前置条件失败，因此需要依赖生成器，让一些值依赖于其他值，确保输入在构造时就是有效的。
生成器与属性并非相互独立，生成器执行的计算可能与随机生成本身无关。如在处理 `Database` 时，因太复杂无法从头生成，需先生成简单版本，再用其 API 构建。同时，可将属性的一部分移到生成器中，让属性变为全函数，生成器变为部分函数。
QuickCheck 支持基于属性的测试编写方式，通过 `forAll` 组合器接受生成器，创建可访问生成值的上下文，使属性成为包含生成和断言的测试。这表明基于属性的测试是属性和生成器的结合，很多时候不打破抽象边界就无法使用这些属性。
不同的 PBT 框架在处理抽象边界时表现不同。Haskell 的 QuickCheck 的 Rust 移植版 `quickcheck` 没有处理好抽象边界，其 `quicktest` 期望一个 `Testable` 实例，设计假设了不充分的边界，计算可能需要与生成过程交织在一起。Proptest 也做出了类似决定。
新推出的 [Hegel](https://github.com/hegeldev/hegel-rust) 保留了 `tc: TestCase` 参数，允许将生成与测试用例混合，通过不同机制实现了 Haskell 中的原始功能，而 Hypothesis 早已使用这种机制。
编辑观点：基于属性的测试在软件开发中具有重要意义，但目前各框架在处理属性与生成器关系及抽象边界上存在差异。开发者需根据具体需求选择合适框架，未来框架应更好融合生成与属性，提升可表达性。