18

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

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

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

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

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

4

2 回答 2

3

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

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

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

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

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

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

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

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

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

于 2011-08-12T18:57:36.500 回答
2

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

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

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

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

于 2011-08-12T22:46:42.620 回答