2012-06-12 21 views
7

के साथ इनपुट जेनरेट करके पारसी पार्सर्स का परीक्षण करना मैं पार्ससी पार्सर्स के एक सूट के लिए परीक्षण लिखना चाहता हूं। यहाँ एक पार्सर का एक सरल उदाहरण मैं QuickCheck साथ परीक्षण करना चाहते है:क्विक चेक

identifier = do 
    c <- letter 
    cs <- many (alphaNum <|> oneOf identSymbols) 
    skipSpaces 
    return $ Ident $ c:cs 

तो, आदर्श, मैं QuickCheck वैध पहचानकर्ता पैदा करते हैं और यकीन है कि मैं सही परिणाम वापस पाने के साथ-साथ अवैध पहचानकर्ता पैदा यह सुनिश्चित करना चाहते और सुनिश्चित करें कि वे ParseError लौटते हैं। क्या ऐसी कोई उपयोगिताएं हैं जो इस तरह की चीज को आसान बनाती हैं? क्या ऐसा कोई तरीका है जिससे मैं अपने पार्सर को रिवर्स में चला सकता हूं, ताकि बोलने के लिए, ऐसे इनपुट उत्पन्न कर सकें?

सामान्य रूप से, इस पार्सर के लिए क्विक चेक परीक्षणों का एक अच्छा सूट कैसा दिखता है? कुछ हद तक, ऐसा लगता है कि मुझे पूरी तरह से परीक्षण करने के लिए क्विक चेक में पार्सर के तर्क को डुप्लिकेट करना होगा। क्या यह वास्तव में एक अच्छा विचार है, या शायद यह एक ऐसी स्थिति है जहां हनीट जैसे अधिक पारंपरिक उपकरण क्विक चेक से अधिक उपयुक्त हैं?

उत्तर

13

सामान्य रूप से, एक पार्सर के विपरीत एक सुंदर प्रिंटर है, और एक पार्सर में यादृच्छिक इनपुट के विपरीत, एक एएसटी की यादृच्छिक सुंदर प्रिंटिंग है।

तो, usual approach का पालन करें और अपने एएसटी के लिए एक मनमाना उदाहरण परिभाषित करें, जो यादृच्छिक अच्छी तरह से गठित वाक्यविन्यास टुकड़े चलाता है। त्रुटि प्रबंधन के लिए परीक्षण करने के लिए कुछ ग़लत वर्णों में एक रैपर के रूप में मिलाएं।

यह भी देखें:

+0

एक विशेष संपत्ति जिसे मैं उपयोग करना चाहता हूं वह है parse = parse। सुंदर । पार्स। यह पार्सर द्वारा जानकारी के उद्धरण को मॉडल करने के लिए एक सभ्य तरीका के रूप में कार्य करता है, सैद्धांतिक परिप्रेक्ष्य से इसे चलाने के लिए एक अच्छा जुड़ाव है, और यह उस तथ्य को कैप्चर करता है जो सुंदर है। पहचान कार्य नहीं है, तो पार्स बेवकूफ़ है। (आमतौर पर पार्सिंग कुछ जानकारी छोड़ देता है) –

+2

पिछले दो लिंक मर चुके हैं –

संबंधित मुद्दे