QuickCheck实例在一个cabal包中属于哪里？ [英] Where do QuickCheck instances belong in a cabal package?

问题描述

我有一个 cabal软件包，用于导出 NBT 可能对其他用户有用开发人员。我经历了为我的类型定义一个 Arbitrary 实例的麻烦，如果不能将它提供给其他开发人员来测试他们集成了我的工作的代码，那将是一件很遗憾的事情。

然而，我想避免我的实例可能受阻碍的情况。也许其他开发者有不同的想法对于任意实例应该是什么。也许我的包依赖于特定版本的QuickCheck可能会干扰客户端项目的依赖关系，或者是不需要的。

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

• 在类型定义旁边保留任意实例，并让客户处理使用阴影实例或覆盖QuickCheck版本号。
  
• 将任意实例作为孤立实例放在同一个包中的单独模块中，例如 Data.NBT.Arbitrary 。


• 在完全独立的软件包中提供任意实例，以便它可以被列出作为客户端项目的单独测试依赖项。
  
• 有条件地在主包中包含任意实例和QuickCheck依赖项，但仅限于如果设置了像 -ftest 这样的标志。

我见过组合所有这些在其他图书馆中使用，但没有找到任何共识，最有效的。我想在上传到Hackage之前尝试做好准备。

解决方案

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

如果可能的话，任意实例是详细的（因此对于不同的人来说不太可能改变），所以最好将它与你的软件包一起发货，特别是如果你要确保你不断更新软件包（例如使用标志或不，这归结于一些个人偏好）。如果实例相对简单（因此人们更希望定制它），那么在文档中提供示例实例可能是一个想法。

如果这个类型主要是内部的，并且不太可能被其他想要运行测试的用户使用，那么使用一个标志来有条件地引入QuickCheck可能是避免不必要的依赖关系的最好方法（即测试套件在那里

我并不喜欢只有QuickCheck的软件包，尽管它可能是在某些情况下很有用。

I have a cabal package that exports a type NBT which might be useful for other developers. I've gone through the trouble of defining an Arbitrary instance for my type, and it would be a shame to not offer it to other developers for testing their code that integrates my work.

However, I want to avoid situations where my instance might get in the way. Perhaps the other developer has a different idea for what the Arbitrary instance should be. Perhaps my package's dependency on a particular version of QuickCheck might interfere with or be unwanted in the dependencies of the client project.

My ideas, in no particular order, are:

• Leave the Arbitrary instance next to the definition of the type, and let clients deal with shadowing the instance or overriding the QuickCheck version number.
• Make the Arbitrary instance an orphan instance in a separate module within the same package, say Data.NBT.Arbitrary. The dependency on QuickCheck for the overall package remains.
• Offer the Arbitrary instance in a totally separate package, so that it can be listed as a separate test dependency for client projects.
• Conditionally include both the Arbitrary instance and the QuickCheck dependency in the main package, but only if a flag like -ftest is set.

I've seen combinations of all of these used in other libraries, but haven't found any consensus on which works best. I want to try and get it right before uploading to Hackage.

解决方案

The problem comes down to: how likely is it that someone using your library will be wanting to run QuickCheck tests using your NBT type?

If it is likely, and the Arbitrary instance is detailed (and thus not likely to change for different people), it would probably be best to ship it with your package, especially if you're going to make sure you keep updating the package (as for using a flag or not, that comes down to a bit of personal preference). If the instance is relatively simple however (and thus more likely that people would want to customise it), then it might be an idea to just provide a sample instance in the documentation.

If the type is primarily internal in nature and not likely to be used by others wanting to run tests, then using a flag to conditionally bring in QuickCheck is probably the best way to go to avoid unnecessary dependencies (i.e. the test suite is there just so you can test the package).

I'm not a fan of having QuickCheck-only packages in general, though it might be useful in some situations.

这篇关于QuickCheck实例在一个cabal包中属于哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！