मैं पार्सर के लिए यूनिट टेस्ट केस कैसे लिख सकता हूं?

Question

मैं एक पार्सर लिख रहा हूं जो प्रत्येक कमांड के लिए 32 बिट ऑपोड उत्पन्न करता है। उदाहरण के लिए, निम्न कथन के लिए:

set lcl_var = 2 

मेरी पार्सर उत्पन्न करता है निम्नलिखित opcodes:

// load immdshort 2 (loads the value 2) 
0x10000010 
// strlocal lclvar (lcl_var is converted to an index to identify the var) 
0x01000002 

कृपया ध्यान दें कि lcl_var कुछ भी यानि हो सकता है, किसी भी चर दिया जा सकता है। इसके लिए यूनिट टेस्ट केस कैसे लिख सकते हैं? क्या हम मूल्यों को कड़ी मेहनत से बच सकते हैं? क्या इसे सामान्य बनाने का कोई तरीका है?

Answer 1

आप यह निर्दिष्ट नहीं करते कि आप कौन सी भाषा पार्सर लिख रहे हैं, इसलिए मैं तर्क के लिए यह मानने जा रहा हूं कि आप ऑब्जेक्ट उन्मुख भाषा का उपयोग कर रहे हैं।

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

यदि आपकी गंतव्य कक्षा आसानी से विस्तारणीय नहीं है, तो आप इस पर आधारित एक इंटरफ़ेस बनाना चाहेंगे कि गंतव्य वर्ग और आपकी नकली कक्षा दोनों लागू हो सकती हैं।

Answer 2

मैं यह समझ के रूप में, आप पहली बार अपने विशिष्ट उदाहरण, यानी जहां अपने पार्सर के लिए इनपुट है के लिए एक परीक्षण लिखना होगा:

set lcl_var = 2 

और आउटपुट है:

0x10000010 // load immdshort 2 
0x01000002 // strlocal lclvar 

जब आप उस परीक्षा को पास करने के लिए उत्पादन कोड लागू किया है, और इसे दोबारा दोहराया है, तो यदि आप संतृप्त नहीं हैं तो यह किसी भी स्थानीय चर को संभाला जा सकता है, एक अलग स्थानीय चर के साथ एक और परीक्षण लिख सकता है और देख सकता है कि यह गुजरता है या नहीं। जैसे इनपुट के साथ नया परीक्षण:

set lcl_var2 = 2 

और अपने इच्छित परीक्षण को उम्मीद करने के लिए अपना नया परीक्षण लिखें। ऐसा तब तक करें जब तक आप संतुष्ट न हों कि आपका उत्पादन कोड पर्याप्त मजबूत है।

Answer 3

यह इस बात पर निर्भर करता है कि आपने अपने पार्सर को कैसे संरचित किया है। एक यूनिट-टेस्ट एक यूनिट परीक्षण करता है।

तो, यदि आप अपने पूरे पार्सर को एक इकाई के रूप में जांचना चाहते हैं, तो आप इसे कमांड की एक सूची दे सकते हैं और सत्यापित कर सकते हैं कि यह सही ऑपकोड उत्पन्न करता है (जिसे आपने मैन्युअल रूप से जांचते समय मैन्युअल रूप से चेक किया था)। आप प्रत्येक कमांड के लिए परीक्षण लिख सकते हैं, और सामान्य उपयोग, एज-केस उपयोग, बस-परे-एज-केस उपयोग का परीक्षण कर सकते हैं। उदाहरण के लिए, कि परीक्षण:

सेट lcl_var = 2

परिणामों में:

0x10000010 0x01000002

और 0 के लिए एक ही, -1, MAX_INT -1, MAX_INT + 1,। ..

आप इन मानों के लिए सही परिणाम जानते हैं। विभिन्न चर के लिए वही चला जाता है।

Answer 4

int[] opcodes = Parser.GetOpcodes("set lcl_var = 2"); 
Assert.AreEqual(2, opcodes.Length); 
Assert.AreEqual(0x10000010, opcodes[0]); 
Assert.AreEqual(0x01000002, opcodes[1]); 

Answer 5

यदि आपका सवाल "प्रति इनपुट-आउटपुट संयोजन एक XUnit परीक्षण लेखन के बिना मैं विभिन्न आदानों और अपेक्षित मानों के साथ एक ही परीक्षण कैसे चला सकता हूँ?" है

तब इसका उत्तर RowTest NUnit एक्सटेंशन जैसे कुछ का उपयोग करना होगा। मैंने हाल ही में अपने ब्लॉग पर quick bootup post लिखा था। इस का एक उदाहरण होगा

[TestFixture] 
    public class TestExpression 
    { 
     [RowTest] 
     [Row(" 2 + 3 ", "2 3 +")] 
     [Row(" 2 + (30 + 50) ", "2 30 50 + +")] 
     [Row(" ((10+20) + 30) * 20-8/4 ", "10 20 + 30 + 20 * 8 4/-")] 
     [Row("0-12000-(16*4)-20", "0 12000 - 16 4 * - 20 -")] 
     public void TestConvertInfixToPostfix(string sInfixExpr, string sExpectedPostfixExpr) 
     { 
      Expression converter = new Expression(); 
      List<object> postfixExpr = converter.ConvertInfixToPostfix(sInfixExpr); 

      StringBuilder sb = new StringBuilder(); 
      foreach(object term in postfixExpr) 
      { 
       sb.AppendFormat("{0} ", term.ToString()); 
      } 
      Assert.AreEqual(sExpectedPostfixExpr, sb.ToString().Trim()); 
     } 

Answer 6

यह स्पष्ट नहीं है कि आप देख रहे हैं एक पद्धति या अपने परीक्षण के लिए उपयोग करने के लिए एक विशिष्ट प्रौद्योगिकी के लिए।

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

लेने का एक और तरीका स्वचालित रूप से अपेक्षित ऑपोड के साथ आपकी डोमेन विशिष्ट भाषा में प्रोग्राम जेनरेट करना है। यह एक पर्ल स्क्रिप्ट है कि जैसे कार्यक्रमों का एक सेट का उत्पादन लेखन की तरह बहुत आसान हो सकता है:

सेट lcl_var = 2

सेट lcl_var = 3

एक बार जब आप अपनी भाषा में परीक्षण कार्यक्रमों का एक सूट है सही आउटपुट है, आप पीछे की तरफ जा सकते हैं और यूनिट परीक्षण उत्पन्न कर सकते हैं जो प्रत्येक ऑपोड को जांचते हैं। चूंकि आपके पास पहले से ही ऑपकोड हैं, इसलिए यह सहीता के लिए पार्सर के आउटपुट का निरीक्षण करने का मामला बन गया है; अपने कोड की समीक्षा।

जबकि मैंने cppunit का उपयोग नहीं किया है, मैंने एक इन-हाउस टूल का उपयोग किया है जो बहुत सी cununit की तरह था। Cppunit का उपयोग कर यूनिट परीक्षणों को कार्यान्वित करना आसान था।

Answer 7

आप क्या परीक्षण करना चाहते हैं? क्या आप जानना चाहते हैं कि सही "स्टोर" निर्देश बनाया गया है या नहीं? क्या सही चर उठाया गया है? अपना मन बनाओ जिसे आप जानना चाहते हैं और परीक्षण स्पष्ट होगा। जब तक आप नहीं जानते कि आप क्या हासिल करना चाहते हैं, तो आपको पता नहीं चलेगा कि अज्ञात का परीक्षण कैसे करें।

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

आज, उस व्यक्ति बनने की कोशिश न करें जो आप कल होंगे।