2011-01-23 5 views
8

क्विक चेक के माध्यम से परीक्षण किए जाने पर असफल संपत्ति परीक्षण के कारणों को प्रदर्शित करने का सबसे अच्छा अभ्यास क्या है?क्विक चेक के साथ एक असफल परीक्षण संपत्ति का कारण कैसे प्रदर्शित करें?

उदाहरण के लिए विचार करें:

prop a b = res /= [] 
    where 
     (res, reason) = checkCode a b 

फिर एक सत्र दिखाई देगा:

> quickCheck prop 
Falsifiable, after 48 tests: 
42 
23 

लेकिन यह डीबगिंग के लिए quickCheck falsifable के हिस्से के रूप विफलता का कारण दिखाने के लिए वास्तव में सुविधाजनक होगा रिपोर्ट।

मैं इसे इस तरह हैक कर लिया है:

prop a b = if res /= [] then traceShow reason False else True 
    where 
     (res, reason) = checkCode a b 

वहाँ एक बेहतर/अच्छे या अधिक quickcheckish तरह से यह करने के लिए है?

उत्तर

9

मुझे लगता है कि आपके "कारण" चर में कुछ गलत परीक्षण किए गए परीक्षण-विशिष्ट डेटा शामिल हैं। आप इसके बजाय "परिणाम" वापस कर सकते हैं, जिसमें सफलता/असफल/अमान्य स्थितियां और एक स्ट्रिंग शामिल है जो गलत हो गई है। प्रॉपर्टी जो रिटर्न परिणाम को क्विक चेक द्वारा ठीक उसी तरह से संभाला जाता है जैसे बूल लौटाता है।

इस तरह (संपादित करें):

module QtTest where 

import Test.QuickCheck 
import Test.QuickCheck.Property as P 


-- Always return success 
prop_one :: Integer -> P.Result 
prop_one _ = MkResult (Just True) True "always succeeds" False [] [] 


-- Always return failure 
prop_two :: Integer -> P.Result 
prop_two n = MkResult (Just False) True ("always fails: n = " ++ show n) False [] [] 

नोट है कि यह "परिणाम" प्रकार Test.QuickCheck.Property में परिभाषित आप चाहते है।

भी मुझे लगता है कि यह उन का उपयोग करना बेहतर शैली होगा इस तरह के

prop_three :: Integer -> Property 
prop_three n = printTestCase ("always fails: n = " ++ show n) False 

के रूप में कुछ combinators Test.QuickCheck.Property में परिभाषित किया गया है जो आप नहीं बल्कि निर्माता को सीधे फ़ोन से परिणाम रचना मदद, कर रहे हैं।

+0

क्या आप एक साधारण उदाहरण दे सकते हैं कि परिणाम को वास्तव में कैसे वापस करना है जैसे कि "कारण" चर (मान लें कि यह कुछ स्ट्रिंग या शो-सक्षम मान है) विफलता के मामले में प्रदर्शित होता है? – maxschlepzig

+0

अद्यतन के लिए धन्यवाद। मुझे http://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html पर भी ठीक किया गया था और अद्यतित और व्यापक मॉड्यूल दस्तावेज़ों में नहीं देखा गया था http://hackage.haskell.org/packages/ संग्रह/क्विक चेक/2.4.0.1/डॉक्टर/एचटीएमएल/टेस्ट-क्विक चेक-प्रॉपर्टी.html - ऐसा लगता है कि 'प्रिंटटेस्टकेस' हालिया जोड़ा है - क्विक चेक 2.1 इसमें शामिल नहीं है। – maxschlepzig

2

क्योंकि क्विक चेक आपको फ़ंक्शन में इनपुट देता है, और क्योंकि परीक्षण के तहत कोड शुद्ध है (यह सही है?), आप केवल उन इनपुट को फ़ंक्शन में खिला सकते हैं और परिणाम प्राप्त कर सकते हैं। यह अधिक लचीला है, क्योंकि उन इनपुट के साथ आप मूल कार्य में बार-बार परीक्षण के साथ परीक्षण कर सकते हैं जब तक कि यह सही न हो।

+2

अच्छा, प्रश्न का बिंदु सुविधा है। सफल परीक्षण जितना संभव हो उतना स्वचालित करने के बारे में है। एक ghci सत्र खोलने और एक संभावित महंगी समारोह recomputing करने के लिए समझ में नहीं आता है। मेरा मतलब है, क्विक चेक पहले से ही 'संग्रह' प्रदान करता है, 'वर्गीकृत' * गैर-असफल * संपत्ति परीक्षणों के आउटपुट को समृद्ध करने में सक्षम होने के लिए। इस तरह का संवर्धन वैकल्पिक है और लचीलापन कम नहीं करता है। – maxschlepzig

+1

मेरा मतलब है, इसके लिए एक व्यावहारिक कारण भी है: क्विक चेक गुण मनमाने ढंग से जटिल हो सकते हैं, इसलिए यह आवश्यक नहीं है कि किसी दिए गए परीक्षण का "आउटपुट" क्या है: आपको अपने कोड को एक ऐसे रूप में मालिश करने की आवश्यकता होगी जो कहती है "हे , यहां उन मध्यवर्ती मूल्य हैं जिन्हें मैं रूचि रखता हूं! " मान लीजिए कि आप इस पुनर्लेखन को करने के इच्छुक हैं, हालांकि, इस कारण के लिए कोई कारण नहीं है कि आप इस क्षमता को प्रदान नहीं कर सके, हालांकि आईआईआरसी क्विक चेक में इस उद्देश्य के लिए कुछ बेक नहीं है। –