सी ++ परीक्षण ऐप्स और संबंधित फाइलों को व्यवस्थित करने के लिए कैसे करें?

Question

मैं एक सी ++ लाइब्रेरी पर काम कर रहा हूं कि (अन्य सामानों के साथ) कॉन्फ़िगरेशन फ़ाइलों को पढ़ने के लिए कार्य करता है; और मैं इसके लिए परीक्षण जोड़ना चाहता हूं। अब तक, इसने मुझे बहुत सारी वैध और अमान्य कॉन्फ़िगरेशन फाइलें बनाने के लिए प्रेरित किया है, प्रत्येक में केवल कुछ पंक्तियां हैं जो एक विशिष्ट कार्यक्षमता का परीक्षण करती हैं। लेकिन अब यह बहुत ही कमजोर हो गया है, क्योंकि बहुत सारी फाइलें हैं, और बहुत सी छोटी सी ++ टेस्ट एप्स भी हैं। किसी भी तरह यह मेरे लिए गलत लगता है :-) तो क्या आपको संकेत है कि इन सभी परीक्षणों, परीक्षण ऐप्स और परीक्षण डेटा को कैसे व्यवस्थित किया जाए?

नोट: लाइब्रेरी का सार्वजनिक एपीआई स्वयं आसानी से टेस्ट करने योग्य नहीं है (इसे पैरामीटर के रूप में कॉन्फ़िगरेशन फ़ाइल की आवश्यकता होती है)। वास्तव में कॉन्फ़िगरेशन मानों को पढ़ने और व्याख्या करने के लिए रसदार, बग-प्रवण विधियां निजी हैं, इसलिए मुझे सीधे परीक्षण करने का कोई तरीका नहीं दिख रहा है?

तो: क्या आप असली फाइलों के खिलाफ परीक्षण के साथ चिपके रहेंगे; और यदि हां, तो आप इन सभी फ़ाइलों और ऐप्स को कैसे व्यवस्थित करेंगे ताकि वे अभी भी बनाए रख सकें?

Answer 1

शायद पुस्तकालय किसी प्रकार का स्ट्रीम इनपुट स्वीकार कर सकता है, तो आप एक स्ट्रिंग-जैसी ऑब्जेक्ट में पास हो सकते हैं और सभी इनपुट फ़ाइलों से बच सकते हैं? या कॉन्फ़िगरेशन के प्रकार के आधार पर, आप "get/setAttribute()" फ़ंक्शंस को सीधे, सार्वजनिक रूप से, पैरामीटर को खराब करने के लिए प्रदान कर सकते हैं। यदि यह वास्तव में एक डिजाइन लक्ष्य नहीं है, तो कभी भी बुरा मत मानो। डेटा-संचालित यूनिट परीक्षण कुछ स्थानों पर फंसे हुए हैं, लेकिन यह निश्चित रूप से कुछ भी नहीं है! मैं शायद इस तरह कोड बाहर रखना होगा:

project/ 
      src/ 
      tests/ 
       test1/ 
         input/ 
       test2 
         input/ 

प्रत्येक testN निर्देशिका में आप इनपुट निर्देशिका में config फ़ाइलों से जुड़े एक cpp फ़ाइल होगा।

उसके बाद, आप यह सोचते हैं एक XUnit शैली परीक्षण पुस्तकालय (cppunit, googletest, unittest++, या जो कुछ भी) आप एक ही वर्ग की कार्यक्षमता का संबद्ध समूहों का परीक्षण करने के लिए विभिन्न testXXX() फ़ंक्शन में जोड़ सकते हैं का उपयोग कर रहे हैं। इस तरह आप कम-से-कम कुछ परीक्षणों को समूहबद्ध करके बहुत कम-छोटी-छोटी समस्याओं की समस्या काट सकते हैं।

इसके साथ एकमात्र समस्या यह है कि लाइब्रेरी कॉन्फ़िगरेशन फ़ाइल को कुछ विशिष्ट कहलाता है, या किसी विशिष्ट स्थान पर होने की अपेक्षा करता है। यह मामला नहीं होना चाहिए, लेकिन यदि आपकी टेस्ट फ़ाइल को अपेक्षित स्थान पर कॉपी करके इसे काम करना होगा।

और अपने प्रोजेक्ट को अपनाने के कई परीक्षणों के बारे में चिंता न करें, अगर उन्हें किसी परीक्षण निर्देशिका में टकराया जाता है तो वे किसी को भी परेशान नहीं करेंगे।

Answer 2

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

Answer 3

मैं @ रिचर्ड क्विर्क ने जो कहा उससे सहमत हूं, लेकिन आप भी अपने टेस्ट सूट क्लास को उस कक्षा के मित्र बना सकते हैं जिसका आप परीक्षण कर रहे हैं और अपने निजी कार्यों का परीक्षण कर सकते हैं।

Answer 4

भाग 1.

के रूप में रिचर्ड का सुझाव दिया, मैं CPPUnit परीक्षण ढांचे पर एक नज़र डालें चाहते हैं। यह आपके परीक्षण ढांचे के स्थान को कुछ हद तक ड्राइव करेगा।

आपके परीक्षण रिचर्ड के उदाहरण के अनुसार, या परीक्षण उपनिर्देशिका या परीक्षण क्षेत्र में समानांतर परीक्षण निर्देशिका के अनुसार उच्च स्तर पर स्थित समांतर निर्देशिका में हो सकते हैं।

किसी भी तरह से, कृपया परियोजना में निर्देशिका संरचना में सुसंगत रहें! विशेष रूप से एक उच्च उच्च स्तरीय निर्देशिका में परीक्षण किए जाने वाले परीक्षणों के मामले में।

बदतर कुछ भी नहीं है इस तरह के रूप में एक स्थान में स्रोत कोड की एक मानसिक मानचित्रण बनाए रखने के लिए की तुलना में:

/project/src/component_a/piece_2/this_bit 

और परीक्षण (रों) स्थित होने कहीं, जैसे कि:

/project/test/the_first_components/connection_tests/test_a 

और मैंने परियोजनाओं पर काम किया है जहां किसी ने ऐसा किया था!

गीलेवेयर चक्रों का कितना अपशिष्ट! 8-ओ किसी नाम के बिना अलेक्जेंडर की गुणवत्ता की अवधारणा का उल्लंघन करने के बारे में बात करें।

आपके परीक्षण लगातार चल रहे हैं w.r.t. परीक्षण के अंतर्गत स्रोत कोड के स्थान:

/project/test/component_a/piece_2/this_bit/test_a 

भाग 2

एपीआई config फ़ाइलों के लिए के रूप में, परीक्षण env के एक भाग के रूप में प्रत्येक स्थानीय परीक्षण क्षेत्र में एक संदर्भ config की स्थानीय कॉपी करते हैं। एक परीक्षण निष्पादित करने से पहले चलाया गया सेटअप। अपने परीक्षण पेड़ के माध्यम से कॉन्फ़िगरेशन (या डेटा) की प्रतियां छिड़काएं।

एचटीएच।

चियर्स,

रोब

BTW सच है जब चीजें की स्थापना आप इस अब पूछ देखकर खुश!

Answer 5

इस तरह की चीजों के लिए मेरे पास हमेशा एक छोटी उपयोगिता कक्षा होती है जो एक मेमोरी बफर में कॉन्फ़िगर लोड करेगी और वहां से इसे वास्तव में कॉन्फ़िगरेशन क्लास में खिलाया जाएगा। इसका मतलब है कि वास्तविक स्रोत कोई फर्क नहीं पड़ता - यह एक फ़ाइल या डीबी हो सकता है। यूनिट-टेस्ट के लिए यह एक std :: स्ट्रिंग में हार्ड कोड किया जाता है जिसे परीक्षण के लिए कक्षा में पास किया जाता है। विफलता पथों का परीक्षण करने के लिए आप आसानी से currup! Pte3d डेटा अनुकरण कर सकते हैं।

मैं UnitTest++ का उपयोग करता हूं। मेरे पास स्रोत पेड़ के हिस्से के रूप में परीक्षण हैं। तो:

solution/project1/src <-- source code 
solution/project1/src/tests <-- unit test code 
solution/project2/src <-- source code 
solution/project2/src/tests <-- unit test code 

Answer 6

मान लिया जाये कि आप पुस्तकालय के डिजाइन पर नियंत्रण है कि, मैं उम्मीद होती है कि आप ऐसी है कि आप वास्तविक फ़ाइल एक विन्यास फाइल के रूप में यह व्याख्या से पढ़ने की चिंताओं को अलग refactor करने के लिए सक्षम होगा:

1. वर्ग FileReader फ़ाइल पढ़ता है और एक इनपुट धारा पैदा करता है,
2. वर्ग ConfigFileInterpreter सत्यापित करता/व्याख्या आदि इनपुट धारा की सामग्री

अब FileReader का परीक्षण करने के लिए आपको बहुत कम वास्तविक फाइलों (खाली, बाइनरी, सादा पाठ इत्यादि) की आवश्यकता होगी, और ConfigFileInterpreter के लिए आप FileReader क्लास के स्टब का उपयोग करेंगे जो पढ़ने के लिए इनपुट स्ट्रीम देता है। अब आप अपनी सभी कॉन्फ़िगरेशन स्थितियों को तारों के रूप में तैयार कर सकते हैं और आपको इतनी सारी फाइलें पढ़ने की आवश्यकता नहीं होगी।

Answer 7

आपको CppUnit से भी एक इकाई परीक्षण ढांचा नहीं मिलेगा। गंभीरता से, कोई भी जो सीपीपीयूनीट की सिफारिश करता है, उसने वास्तव में प्रतिस्पर्धात्मक ढांचे में से किसी एक को नहीं देखा है।

तो हाँ, यूनिट परीक्षण फ़्रैनवर्क के लिए जाएं, लेकिन CppUnit का उपयोग न करें।