क्या एपीआई के लिए एक रैपर का परीक्षण करते समय मेरे यूनिट परीक्षण सीधे एपीआई को छूना चाहिए?

Question

मैंने कुछ यूनिट परीक्षणों को लिखा है जो एक FTP सर्वर API के आस-पास एक रैपर का परीक्षण करते हैं।

यूनिट परीक्षण और FTP सर्वर दोनों एक ही मशीन पर हैं।

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

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

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

इस गंध बुरा है?

अद्यतन 1: @ जेरेमी/निक: रैपर परीक्षण का केंद्र है, एफ़टीपी सर्वर और इसकी COM एपीआई तीसरे पक्ष के उत्पाद हैं, संभवतः अच्छी तरह से परीक्षण और स्थिर हैं। रैपर एपीआई को एक्सएमएल संदेश का विश्लेषण करना है और फिर एफ़टीपी सर्वर के एपीआई का आह्वान करना है। मैं कैसे सत्यापित करूं, और यह एक मूर्ख मामला हो सकता है, कि उपयोगकर्ता खाते की एक विशेष संपत्ति रैपर द्वारा सही ढंग से सेट की गई है। उदाहरण के लिए रैपर कोड में टाइपो के कारण गलत संपत्ति या FTP खाते की विशेषता सेट करना। एक अच्छा उदाहरण अपलोड करने और गति सीमा डाउनलोड करने के लिए, यह रैपर कोड में स्थानांतरित हो सकता है।

अपडेट 2: उत्तर के लिए सभी को धन्यवाद। लोग mocks का उपयोग कर सुझाव के लिए, यह मेरे मन को पार किया था, लेकिन प्रकाश वहाँ पर अभी तक परिवर्तित नहीं किया है और मैं अभी भी अपने सिर दौर पाने के लिए मैं FTP सर्वर के एक नकली के साथ काम करने के लिए अपने आवरण मिलेगा संघर्ष कर रहा हूँ । मोजे कहाँ रहते हैं और क्या मैं COM API को कॉल करने के बजाय उपयोग करने के लिए रैपर एपीआई में कहा गया मैक्स का एक उदाहरण पास करता हूं? मैं मजाक करने के बारे में जानता हूं लेकिन मेरे सिर को घेरने के लिए संघर्ष कर रहा हूं, अधिकतर क्योंकि मुझे लगता है कि अधिकांश उदाहरण और ट्यूटोरियल इतने अमूर्त हैं और (मुझे कहना शर्मिंदा है) समझ में नहीं आता है।

Answer 1

आप मिश्रण इकाई & घटक परीक्षण चिंताओं होने लगते हैं।

• यदि आप अपने रैपर को यूनिट-परीक्षण कर रहे हैं, तो आपको एक नकली FTP सर्वर का उपयोग करना चाहिए और वास्तविक सर्वर को शामिल नहीं करना चाहिए। प्लस साइड है, आप आमतौर पर इस तरह 100% स्वचालन प्राप्त कर सकते हैं।
• यदि आप घटक परीक्षण पूरी बात (एक साथ काम आवरण + FTP सर्वर), अपने आवरण एपीआई के माध्यम से अपने परीक्षण अर्थात के रूप में एक ही स्तर पर अपने परिणामों की पुष्टि करने के लिए प्रयास करें। उदाहरण के लिए, यदि आप फ़ाइल अपलोड करने के लिए कोई आदेश जारी करते हैं, तो अगला, यह सुनिश्चित करने के लिए कि फ़ाइल सही तरीके से अपलोड की गई थी, उस फ़ाइल को हटाने/डाउनलोड करने के लिए कमांड जारी करें। अधिक जटिल परिचालनों के लिए जहां परिणाम का परीक्षण करने के लिए यह छोटा नहीं है, फिर आपके द्वारा उल्लिखित COM API "बैकडोर" का उपयोग करने पर विचार करें या शायद कुछ मैन्युअल सत्यापन शामिल करें (क्या आपके सभी परीक्षणों को स्वचालित करने की आवश्यकता है?)।

Answer 2

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

Answer 3

मैं कहूंगा कि अपने एपीआई सिर्फ एक डेटाबेस या जब परीक्षण एक नेटवर्क कनेक्शन की तरह व्यवहार किया जाना चाहिए। इसका परीक्षण न करें, यह आपके नियंत्रण में नहीं है।

Answer 4

मैं एपीआई को छू नहीं के बारे में निक और जेरेमी के साथ सहमत हैं। मैं एपीआई का मज़ाक उड़ाता हूं।
MOQ:: http://code.google.com/p/moq/

और अन्य मजाक पुस्तकालयों का एक गुच्छा

http://en.wikipedia.org/wiki/Mock_object

यदि यह आप उपयोग कर सकते हैं नेट है।

Answer 5

ऐसा लगता है जैसे आप पूछ रहे हैं "क्या मुझे परीक्षण एपीआई चाहिए?" - आप पूछ रहे हैं "क्या मुझे यह सत्यापित करने के लिए एपीआई का उपयोग करना चाहिए कि मेरा रैपर सही काम कर रहा है या नहीं?"

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

Answer 6

कि क्या एपीआई आवरण कोड वास्तव में सही काम (यदि प्रतिक्रिया सफलता इंगित) किया सत्यापित करने के लिए, मैं FTP सर्वर के COM एपीआई

बंद करो वहीं आह्वान। आपको एफ़टीपी सर्वर का मज़ाक उड़ाया जाना चाहिए और रैपर को नकली के खिलाफ काम करना चाहिए।

अपने परीक्षण दोनों आवरण और FTP सर्वर चलाता है, तो आप यूनिट टेस्टिंग नहीं हैं।

Answer 7

केवल समय मैं जब यह मतलब हो सकता है निचले स्तर एपीआई में डुबकी के लिए परिणामों की पुष्टि करने के लिए यदि यदि उच्च स्तर केवल- API बारे में है के बारे में सोच सकते हैं। उदाहरण के लिए, यदि आप उच्च स्तरीय एपीआई का उपयोग कर उपयोगकर्ता बना सकते हैं, तो उपयोगकर्ता खातों को प्राप्त करने के लिए एक उच्च स्तरीय एपीआई भी होनी चाहिए। उसका उपयोग करें।

अन्य लोगों ने निम्न-स्तर API को मजाक करने का सुझाव दिया है। यह अच्छा है, अगर आप इसे कर सकते हैं। यदि निचले स्तर के घटक का मज़ाक उड़ाया जाता है, तो यह सुनिश्चित करने के लिए कि सही स्थिति सेट है, मॉक्स की जांच ठीक होनी चाहिए।

Answer 8

एक नकली वस्तु के साथ अपने आवरण परीक्षण करने के लिए, आप निम्न कर सकते हैं:

• एक COM वस्तु FTP सर्वर के COM एपीआई के रूप में ही इंटरफ़ेस है कि लिखें। यह आपकी नकली वस्तु होगी। निर्भरता इंजेक्शन के माध्यम से आप अपने रैपर में या तो इंटरफ़ेस पॉइंटर को पार करके वास्तविक FTP सर्वर और अपने नकली ऑब्जेक्ट को इंटरचेंज करने में सक्षम होना चाहिए।
• आपका नकली वस्तु तरीकों इसके इंटरफेस (जो FTP सर्वर एपीआई की नकल करता) पर बुलाया के आधार पर हार्ड-कोडेड व्यवहार को लागू करने और भी इस्तेमाल किया तर्क मूल्यों पर आधारित होना चाहिए:
• उदाहरण के लिए, यदि आप एक UploadFile विधि आप कर सकते हैं है अंधेरे से सफलता परिणाम लौटाएं और शायद उस फ़ाइल नाम को संग्रहीत करें जो तारों की सरणी में पारित किया गया था।
• जब आप इसमें "त्रुटि" के साथ फ़ाइल नाम का सामना करते हैं तो आप एक अपलोड त्रुटि अनुकरण कर सकते हैं।
• जब आप इसमें "धीमी" के साथ फ़ाइल नाम का सामना करते हैं तो आप विलंबता/समय-समय पर अनुकरण कर सकते हैं।
• बाद में, DownloadFile विधि आंतरिक स्ट्रिंग सरणी को जांचने के लिए जांच सकती है कि उस नाम वाली फ़ाइल पहले से ही "अपलोड की गई" थी या नहीं।

कुछ परीक्षण मामलों के लिए छद्म कोड होगा:

//RealServer theRealServer; 
//FtpServerIntf ftpServerIntf = theRealServer.getInterface(); 

// Let's test with our mock instead 
MockServer myMockServer; 
FtpServerIntf ftpServerIntf = myMockServer.getInterface(); 

FtpWrapper myWrapper(ftpServerIntf); 

FtpResponse resp = myWrapper.uploadFile("Testing123"); 
assertEquals(FtpResponse::OK, resp); 

resp = myWrapper.downloadFile("Testing123"); 
assertEquals(FtpResponse::OK, resp); 

resp = myWrapper.downloadFile("Testing456"); 
assertEquals(FtpResponse::NOT_FOUND, resp); 

resp = myWrapper.downloadFile("SimulateError"); 
assertEquals(FtpResponse::ERROR, resp); 

मुझे आशा है कि इस मदद करता है ...