2011-08-09 15 views
13

मैं वर्तमान में के बारे में सोच रहा हूं "ओएसजीआई घटक कैसे डिज़ाइन करें ताकि इसके लिए परीक्षण लिखना आसान हो जैसे जुनीट और मॉकिटो"यूनिट-टेस्टिंग ओएसजीआई-घटक

इंटर-बंडल-निर्भरता का मजाक करना काफी आसान है क्योंकि ओएसजीआई डीआईपी (निर्भरता उलटा सिद्धांत) और इंजेक्टर-विधियों (उदा। सेटटर) को आम तौर पर मौजूद करता है।
लेकिन बंडल आंतरिक निर्भरताओं के बारे में क्या?

उदाहरण के लिए this case देखें। अब मैं इसे ओएसजीआई संदर्भ में लाना चाहता हूं ... छवि हम किसी ओएसजीआई प्लेटफ़ॉर्म में घोषणात्मक सेवा के रूप में किसी भी प्रकार का नेटवर्क प्रोटोकॉल प्रदान करना चाहते हैं और निचले नेटवर्किंग कोड का परीक्षण करने के लिए यूनिट-टेस्ट लिखना चाहते हैं जो सीधे सीधे बातचीत कर रहा है सॉकेट ऑब्जेक्ट।

यदि हम सॉकेट निर्माण को एक अलग लेकिन फिर भी बंडल आंतरिक POJO (सादा ओल्ड जावा ऑब्जेक्ट) कक्षा में दोबारा दोहराएंगे, तो हमें इसे प्रोटोकॉल कार्यान्वयन में कैसे इंजेक्ट करना चाहिए?

  • इकाई परीक्षण में हम बस एक सेटर विधि का उपयोग कर सकते हैं लेकिन हमारे लिए ओएसजीआई कंटेनर में यह कौन करेगा?
  • परीक्षण वर्ग को उपclassing और एक निर्माता-विधि को ओवरराइट करना केवल तभी काम करेगा जब परीक्षण वर्ग को अंतिम के रूप में घोषित नहीं किया जाता है।

उत्तर

8

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

इसके अतिरिक्त आप TinyBundles का उपयोग कर सकते हैं जो आपके परीक्षण (बहुत ठंडा) से गतिशील रूप से तैनाती बंडल/टुकड़े बना सकते हैं ताकि अन्य बंडलों/टुकड़ों को नकल कर सकें ताकि पूर्ण वातावरण लाने के बिना अंतर-बंडल एकीकरण सुनिश्चित किया जा सके।

यूनिट या छोटे पैमाने पर एकीकरण परीक्षण (यानि कंटेनर के बिना) के लिए, तो आप बस बंडल कॉन्टेक्स्ट (या डीएस कंपोनेंट कॉन्टेक्स्ट का उपयोग करके) की नकल कर सकते हैं।

मैं बुलेट बिंदुओं में आपके प्रश्नों के बारे में थोड़ा अस्पष्ट हूं। यदि कोई आंतरिक POJO है तो सेटर्स के माध्यम से निर्भरता को तारित करना आपकी ज़िम्मेदारी होगी, अन्यथा यदि यह ओएसजीआई सेवा रजिस्ट्री के संपर्क में आती है तो निर्भरता ढांचे (या तो डीएस या सर्विसट्रैकर) द्वारा हल की जाती है।

एक निर्माता-विधि को ओवरराइट करने के लिए कुछ भी उप-वर्गीकरण का मतलब है कि अब आप मूल वर्ग का परीक्षण नहीं कर रहे हैं - यह एक कोड गंध है - इसे एक अलग वर्ग (कन्स्ट्रक्टर या सेटर) के रूप में निर्माता कोड में पास करने के लिए इसे पुन: सक्रिय करने का प्रयास करें, फिर इस नए निर्माता कोड (सॉकेट निर्माण) को स्वतंत्र रूप से परीक्षण किया जा सकता है (ओएसजीआई या यहां तक ​​कि प्रोटोकॉल क्लास के लिए कोई विचार नहीं है, जहां इसका उपयोग किया जाएगा)।

+1

यदि मैं ओएसजीआई कंटेनर में चल रहे ओएसजीआई घटक के भीतर पीओजेओ का उपयोग करता हूं, तो घटक को स्वयं पीओजेओ का उदाहरण बनाना होगा। कन्स्ट्रक्टर कोड में कंटेनर इंजेक्ट करने में सक्षम नहीं है। यूनिट-टेस्ट में इस प्रक्रिया को मैं कैसे रोकूं? बेशक मैं एक सेटर विधि बना सकता हूं जो घटक के भीतर पहले बनाए गए POJO को ओवरराइट करेगा लेकिन इसमें कुछ कोड गंध भी है। "क्या हम वास्तव में घटक के कोड का परीक्षण करते हैं जैसे कि यह कंटेनर में चलाएगा?" कन्स्ट्रक्टर कोड में POJO को कॉल करने जैसे कुछ साइड इफेक्ट्स हो सकते हैं और मेरे परीक्षण तोड़ सकते हैं। –

+0

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

+0

परफेक्ट करने के लिए इस सेवा का मज़ाक उड़ाते हैं। एक पारदर्शी सेवा फैक्ट्री का उपयोग करना मैं जो खोज रहा था वह बेहद उत्साहजनक है। पहले मैंने सोचा था कि सेवा कारखानों और घटक कारखाने समान थे। ;) –