他の開発者に役立つ可能性のあるタイプをエクスポートするcabalパッケージがあります。NBT
私はArbitrary
自分のタイプのインスタンスを定義するのに苦労しました。私の仕事を統合するコードをテストするために他の開発者にインスタンスを提供しないのは残念です。
ただし、インスタンスが邪魔になるような状況は避けたいと思います。おそらく、他の開発者は、インスタンスがどうあるべきかについて異なる考えを持っています。Arbitrary
おそらく、QuickCheckの特定のバージョンに対する私のパッケージの依存関係は、クライアントプロジェクトの依存関係に干渉するか、望ましくない可能性があります。
私の考えは、順不同で、次のとおりです。
Arbitrary
タイプの定義の横にインスタンスを残し、クライアントがインスタンスのシャドウイングまたはQuickCheckバージョン番号のオーバーライドを処理できるようにします。Arbitrary
同じパッケージ内の別のモジュールで、インスタンスを孤立したインスタンスにしますData.NBT.Arbitrary
。パッケージ全体のQuickCheckへの依存は残ります。- インスタンスを完全に別個のパッケージで提供し、
Arbitrary
クライアントプロジェクトの別個のテスト依存関係としてリストできるようにします。 - 条件付きで、
Arbitrary
インスタンスとQuickCheck依存関係の両方をメインパッケージに含めますが、のようなフラグ-ftest
が設定されている場合に限ります。
他のライブラリで使用されているこれらすべての組み合わせを見てきましたが、どれが最適に機能するかについてのコンセンサスは見つかりませんでした。Hackageにアップロードする前に試してみたいと思います。