QuickCheck 实例属于阴谋集团 package 的什么位置？

Question

我有一个cabal package导出类型NBT ，这可能对其他开发人员有用。 我经历了为我的类型定义一个Arbitrary实例的麻烦，如果不将它提供给其他开发人员来测试他们集成了我的工作的代码，那将是一种耻辱。

但是，我想避免我的实例可能会妨碍的情况。 也许其他开发人员对Arbitrary实例应该是什么有不同的想法。 也许我的包对特定版本的 QuickCheck 的依赖可能会干扰或不需要客户端项目的依赖。

我的想法，没有特别的顺序，是：

• 将Arbitrary实例保留在类型定义旁边，让客户端处理隐藏实例或覆盖 QuickCheck 版本号。
• 使Arbitrary实例成为同一 package 中的单独模块中的孤立实例，例如Data.NBT.Arbitrary 。 整个 package 对 QuickCheck 的依赖仍然存在。
• 在完全独立的 package 中提供Arbitrary实例，以便它可以作为客户端项目的单独测试依赖项列出。
• 有条件地在主 package 中包含Arbitrary实例和 QuickCheck 依赖项，但前提是设置了-ftest类的标志。

我已经看到在其他库中使用了所有这些的组合，但还没有就哪个效果最好达成任何共识。 我想在上传到 Hackage 之前尝试把它做好。

Answer 1

在没有太多具体经验的基础上，但对健壮性的普遍渴望，package 依赖关系的指导原则应该是

各尽所能； 根据每个人的需要。

最好将 package 的依赖关系保持在其基本功能所需的最低限度。 这对我来说是选项 3 或选项 4。 当然，把 package 砍这么多是很痛苦的。 如果选项能够表达所涉及的条件，那么选项 4 听起来是一种明智的方法，它基于有效地使用语言来表达你的意思。

如果就我们需要轻弹哪个开关来获得测试套件和基本功能达成共识，那将是非常好的。

很明显，这里还有改进的空间。 令人惊讶的是，Cabal 工作得和它一样好，但它可以允许更复杂的“包”概念，也许是在 SML 模块系统的方式之后。 将依赖转换为 function 类型，我们基本上可以写

simplePackage :: (Dependency1, .., Dependencyn) -> Deliverable

但人们可以想象更精细的产品和功能组合，比如

fancyPackage :: BasicDependency -> (BasicDeliverable, HelpfulExtras -> Gravy)

在此之前，请选择最能准确反映实际交易的选项。 告诉我们，这样我们就可以建立共识。

Answer 2

问题归结为：使用您的库的人想要使用您的NBT类型运行 QuickCheck 测试的可能性有多大？

如果可能，并且 Arbitrary 实例很详细（因此不太可能因不同的人而改变），最好将它与 package 一起提供，特别是如果您要确保不断更新 package（至于是否使用旗帜，这取决于个人喜好）。 但是，如果该实例相对简单（因此人们更可能想要自定义它），那么在文档中提供一个示例实例可能是一个想法。

如果该类型本质上主要是内部的并且不太可能被其他想要运行测试的人使用，那么使用标志有条件地引入 QuickCheck 可能是 go 避免不必要的依赖关系的最佳方法（即测试套件就在那里你可以测试这个包）。

我一般不喜欢使用仅限 QuickCheck 的软件包，尽管它在某些情况下可能很有用。