如何從QuickCheck中獲得好（小）縮小？

Question

我試圖在一些嵌套列表上運行QuickCheck，看起來像這樣：

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

所以公式是一個文字列表，每個文字都包含一個謂詞和一些參數; 謂詞/參數是每個字符串形式的約束分離的值。 這給了我們一份列表清單列表，p！

如果我的一個QuickCheck屬性失敗，我傾向於得到一個難以理解的頁面輸出。 在嘗試收縮之前，我曾經通過使用只能生成一小組（小）值的任意實例來解決這個問題。 為我的每個類型實現收縮功能似乎有點幫助，但沒有我想要的那么多。 我仍然得到一頁輸出。

我認為我想要收縮的是一個小文字列表，其中每個文字都有一個小的值列表，而這些值又有很少的約束，每個約束都盡可能短。 但在我目前的努力中，至少這些列表變得足夠大，使輸出變得可怕。 如果我嘗試調整縮小實現，我也發現QC開始花費很長時間（尋找收縮？），這會削弱我有效收縮的努力。

當您嵌套這樣的數據時，如何提高理解QuickCheck失敗的幾率？

Answer 1

FWIW，請看https://github.com/leepike/SmartCheck ，它聲稱可以獲得比人們通常手動更好的收縮。

Answer 2

我有類似的問題，但我使用C和自制的示例生成器:)我有慢和正確，快速和不正確的實現。

使用隨機示例，當您找到不正確的示例時，我建議縮小示例本身。 （當然，這可以或應該由程序而不是計算機來完成）

如果您有此測試的謂詞，並且您有不起作用的示例，請嘗試刪除所有訂單的元素表單列表（這應該是調用的線性數量級），並且如果測試失敗則嘗試每次嘗試。

如果仍然失敗，則沒有理由將此保留在示例中。

如果它開始傳遞，那么這個元素應該保留在縮減的例子中。

（這是貪婪的，不是最優的，但它確實在poly中執行，而不是指數時間，它對我有效）

為了更科學地看，我建議A.Zeller出版的“為什么程序失敗：系統調試指南 ”一書中的“簡化問題”一章。

注意：這主要是收縮的...