クイックチェックから収縮をうまく（小さく）するにはどうすればよいですか？

Question

私は、いくつかのネストされたリストにQuickCheckを実行するには、このようなものしようとしている。だから、式はリテラルのリストであり、そのそれぞれが述語といくつかの引数が含まれてい

type Constraint = Text 
data Value = Value [Constraint] 
data Literal = Literal Value [Value] 
type Formula = [Literal] 

を。述語/引数は、それぞれ文字列形式の制約の論理和である値です。それは私達にリストのリストのリストを提供します、phew！

私のクイックチェックプロパティの1つが失敗した場合、私は分かりにくい出力を得る傾向があります。シュリンクを実験する前に、小さな値の小さな値しか生成できない任意のインスタンスを持つことでこれを回避しました。私のタイプごとにシュリンク関数を実装することは少し助けてくれますが、私が望むほど大きくはありません。私はまだ出力のpagefulを得る。

私が望むものは、リテラルの小さなリストです。各リテラルには値の小さなリストがあり、各リストにはできるだけ短い制約があります。しかし、私の現在の努力では、少なくともこれらのリストは、出力を恐ろしいものにするほど大きくなります。シュリンクの実装を調整しようとすると、QCが非常に長い時間がかかり始める（縮みを検索する）ことがわかります。

このようなネストされたデータを持つと、QuickCheckの失敗を理解する機会はどのように向上しますか？

Answer 1

私は同様の問題を抱えていましたが、私はCと家庭用のサンプルジェネレータを使用していました。私は遅く、正確で、速く、間違った実装をしていました。

誤った例を見つけたら、ランダムな例を使用して、例そのものを縮小することをお勧めします。

このテストの述部を持っていて、うまくいかない例がある場合は、すべての注文の要素フォームリストを削除してみてください（これはもちろん、コンピュータではなくプログラムで行うこともできます） （これは呼び出しの大きさの線形の順序でなければなりません）。

まだ失敗している場合は、これを維持する理由はありません。

この要素が通過を開始すると、この要素は縮小されたままになります。

（これは貪欲と最適ではないですが、それはポリで実行さん、代わりに指数時間の、そしてそれは私のために働いていた）

より科学的な外観のために、私は章を示唆ブック"WHY PROGRAMS FAIL: A Guide to Systematic Debugging"から「問題の簡素化」 A.Zellerによって。

注：これは、大部分であるシュリンクが何をするのか...

Answer 2

FWIW、1は通常、手動で行うことができますより良い収縮を誘導するために主張しhttps://github.com/leepike/SmartCheckを見て、持っています。