2013-10-15 8 views
12

मैं दो अनुप्रयोगों के साथ प्रोजेक्ट पर काम कर रहा हूं: एंड्रॉइड ऐप (क्लाइंट) और बाकी सेवा (सर्वर)। मेरा एंड्रॉइड ऐप मेरी बाकी सेवा का उपभोग करता है।क्लाइंट - सर्वर एकीकरण परीक्षण: नकली या नहीं?

दोनों अनुप्रयोगों को अलग-अलग परीक्षण किया जाता है यह सुनिश्चित करने के लिए कि वे अपेक्षित रूप से अपना व्यवसाय कर रहे हैं। सर्वर परीक्षणों के दौरान मैं अनुरोध तैयार करता हूं और सर्वर प्रतिक्रियाओं की जांच करता हूं। क्लाइंट परीक्षणों के दौरान मैंने एक साधारण http नकली सर्वर स्थापित किया और विभिन्न मॉक किए गए प्रतिक्रियाओं के विरुद्ध क्लाइंट के अनुरोधों का परीक्षण किया।

अब, यह तकनीक बहुत अच्छी तरह से काम करती है। यह मुझे पसंद करता है एक लचीलापन देता है। मैं विभिन्न परीक्षण ढांचे और निरंतर एकीकरण वातावरण का उपयोग कर सकते हैं। लेकिन एक कमजोर बिंदु है। दोनों (क्लाइंट और सर्वर) परीक्षण मामलों में मैं एक ही एपीआई निर्दिष्ट करता हूं। मुझे लगता है कि उदा।

GET /foo-list.json 

HTTP 200 वापस आ जाएगी json

[{ 
    id: 1, 
    name: foo1, 
}, { 
    id: 2, 
    name: foo2 
}] 

साथ तो मैं अपने आप को दोहरा रहे हैं। अगर मैं एक प्रतिक्रिया प्रारूप बदलता हूं तो मेरे क्लाइंट परीक्षण विफल नहीं होंगे।

मेरा प्रश्न इस तरह के परिदृश्य का परीक्षण करने में अच्छी प्रथाओं के बारे में है। स्वतंत्र परीक्षणों की लचीलापन बलिदान के बिना सही एकीकरण परीक्षण कैसे करें। क्या मुझे क्लाइंट को मॉक किए गए सर्वर के साथ या मेरी बाकी सेवा के वास्तविक उदाहरण के साथ परीक्षण करना चाहिए?

कृपया अपना व्यावसायिक अनुभव साझा करें।

उत्तर

7

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

आप से पूछना:

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

इसके अलावा:

"मैं ग्राहक मज़ाक उड़ाया सर्वर के साथ या मेरे बाकी सेवा की एक वास्तविक उदाहरण के साथ परीक्षण करना चाहिए?"

इकाई और एकीकरण परीक्षण आप भी क्लाइंट-सर्वर एकीकरण परीक्षण प्रदर्शन करना चाहिए के अलावा; मैं ऐसा करने के लिए स्वचालित स्वीकृति परीक्षण का उपयोग करता हूं। ककड़ी जैसे टेस्ट फ्रेमवर्क का उपयोग करना (calaba.sh भी देखें जो विशेष रूप से मोबाइल एप्लिकेशन का परीक्षण करने के लिए लिखा गया है) आप उन परीक्षणों को लिख सकते हैं जो विशिष्ट सुविधाओं और परिदृश्यों का परीक्षण करेंगे जो क्लाइंट (आपके एंड्रॉइड एप्लिकेशन) और सर्वर (आपकी रीस्टफुल सेवा दोनों) के साथ बातचीत करेंगे।)। ये क्लाइंट-सर्वर एकीकरण परीक्षण क्लाइंट और सर्वर के ठोस उदाहरणों को शुरू और बंद कर देंगे।

1

यदि आपकी सेवा जावा में आधारित है, तो मैं क्लाइंट से आने वाले किसी भी प्रकार की कॉल का मज़ाक उड़ाने के लिए, स्पॉक फ्रेमवर्क को देखने की दृढ़ता से अनुशंसा करता हूं। चूंकि स्पॉक सिर्फ जुनीट का विस्तार है, इसलिए आप इसे एंड्रॉइड के लिए भी इस्तेमाल कर सकते हैं (हालांकि, निष्पक्ष होने के लिए मैंने एंड्रॉइड डेवलपमेंट कभी नहीं किया है)

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

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

+0

मुझे बताएं कि क्या आप मुझे विस्तृत करना चाहते हैं - मुझे एहसास है कि यह आपके लिए एक उत्तर का थोड़ा सा सामान्य हो सकता है। –

+0

आप दोनों एकीकरण और इकाई परीक्षण की आवश्यकता के बारे में सही हैं। मेरा सवाल * एकीकरण * परीक्षण के बारे में है। जब मैं सेवा के साथ ग्राहक के एकीकरण की जांच करता हूं, तो क्या मुझे सेवा का मज़ाक उड़ाया जाना चाहिए या क्या मुझे सेवा का असली उदाहरण चलाना चाहिए? – promanski

+1

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

4

मोक्स यूनिट परीक्षण के लिए हैं। मोक्स के साथ परीक्षणों का आपका विवरण बिल्कुल वर्णन करता है। आप क्लाइंट और सर्वर को अलग इकाइयों के रूप में जांचते हैं।

इकाइयों एक साथ अच्छी तरह से काम करते हैं तो एकीकरण परीक्षण परीक्षण। चूंकि इंटरफ़ेस एक आरईएसटी इंटरफ़ेस है, इसलिए मॉकिंग को कोई समझ नहीं आता है, तो आपको HTTP पर वास्तविक चीज़ का परीक्षण करना होगा।

भी What is the difference between integration and unit tests?

+0

तो आप एक ग्राहक को बाकी सेवा के वास्तविक उदाहरण के साथ परीक्षण करने की सलाह देते हैं। सही बात? – promanski

+0

सही! एकीकरण परीक्षणों के लिए, इकाइयों को हुक अप करें क्योंकि वे उत्पादन में होंगे। – flup

1

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

यदि आप उन्हें वास्तविक सेवा के विरुद्ध चला सकते हैं तो आप नकली सेवा बनाने का अतिरिक्त काम क्यों करना चाहते हैं?

मैं केवल एक नकली सेवा बनाउंगा, अगर सेवा एक बाहरी सेवा थी जिस पर मेरा कोई नियंत्रण नहीं था!

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