32

次のようなネストされたリストで QuickCheck を実行しようとしています。

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

したがって、式はリテラルのリストであり、それぞれのリテラルには述語といくつかの引数が含まれています。predicate/arguments は、それぞれ文字列形式の制約の論理和である値です。これにより、リストのリストのリストのリストが得られます。

QuickCheck プロパティの 1 つが失敗した場合、理解できないページいっぱいの出力が得られる傾向があります。縮小を試す前に、小さな (小さな) 値のセットしか生成できない任意のインスタンスを用意することで、これを回避していました。私のタイプごとに縮小機能を実装すると、少しは役立つようですが、私が望むほどではありません。まだページ一杯の出力が得られます。

私がシュリンクに求めているのは、リテラルの小さなリストであり、各リテラルには小さな値のリストがあり、制約がほとんどなく、それぞれが可能な限り短いものであると思います。しかし、私の現在の取り組みでは、少なくともこれらのリストのいずれかが大きくなりすぎて、出力がひどいものになってしまいました。シュリンクの実装を調整しようとすると、QC に非常に長い時間がかかるようになり (シュリンクの検索?)、効果的にシュリンクするための努力が妨げられます。

このようにネストされたデータがある場合、QuickCheck の失敗を理解する機会をどのように改善しますか?

4

2 に答える 2

3

FWIW、https://github.com/leepike/SmartCheckを見てください。これは、通常手動で行うよりも優れた縮小を導き出すと主張しています。

于 2012-08-07T20:34:29.807 に答える
1

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

ランダムな例を使用して、間違った例を見つけた場合は、例自体を縮小することをお勧めします。（もちろん、これはコンピューターではなくプログラムによって実行できるか、実行する必要があります）

このテストの述語があり、機能しない例がある場合は、すべての順序（これは呼び出しの大きさの線形順序である必要があります）のリストから要素を削除し、テストに失敗した場合は試行ごとに削除してみてください。

それでも失敗する場合は、これを例にとどめる理由はありません。

それが通過し始めた場合、この要素は縮小された例にとどまるはずです。

（これは貪欲で最適ではありませんが、指数関数的な時間ではなく、ポリで実行され、私にとってはうまくいきました）

より科学的な見方をするために、A.Zellerの著書「WHYPROGRAMS FAIL：A GuidetoSystematicDebugging」の「Simplifyingproblems」の章をお勧めします。

注：これは主に縮小が行うことです...

于 2012-01-24T09:03:03.237 に答える