अन्य उत्तर बताते हैं कि मॉकिंग क्या है। विभिन्न उदाहरणों के साथ आपको इसके माध्यम से चलता हूं । और मेरा विश्वास करो, यह वास्तव में आपके विचार से कहीं अधिक सरल है।
tl; dr यह मूल वर्ग का एक उदाहरण है। इसमें अन्य डेटा इंजेक्ट किया गया है ताकि आप इंजेक्ट किए गए भागों के परीक्षण से बचें और पूरी तरह से अपने वर्ग / कार्यों के कार्यान्वयन विवरणों के परीक्षण पर ध्यान केंद्रित करें।
एक सरल उदाहरण:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
जैसा कि आप देख सकते हैं, मैं LineA का परीक्षण नहीं कर रहा हूँ अर्थात मैं इनपुट मापदंडों को मान्य नहीं कर रहा हूँ। मैं यह देखने के लिए मान्य नहीं हूं कि क्या num1, num2 एक पूर्णांक है। मेरे पास इसके खिलाफ कोई जोर नहीं है।
मैं केवल यह देखने के लिए परीक्षण कर रहा हूं कि क्या लाइनबी (मेरे कार्यान्वयन ) ने नकली मान दिया है 1और 5जैसा मैं उम्मीद करता हूं वैसा ही कर रहा हूं।
स्पष्ट रूप से वास्तविक शब्द में यह बहुत अधिक जटिल हो सकता है। पैरामीटर एक व्यक्ति, कस्टम, या कार्यान्वयन विवरण की तरह एक कस्टम ऑब्जेक्ट हो सकता है एक से अधिक हो सकता है +। लेकिन परीक्षण का तर्क समान होगा।
गैर-कोडिंग उदाहरण:
मान लें कि आप एक ऐसी मशीन बना रहे हैं जो हवाई अड्डे की सुरक्षा के लिए इलेक्ट्रॉनिक उपकरणों के प्रकार और ब्रांड नाम की पहचान करती है। यह मशीन अपने कैमरे से जो कुछ भी देखती है उसे प्रोसेस करके करती है।
अब आपका प्रबंधक द्वार पर चलता है और आपसे इकाई-परीक्षण के लिए कहता है।
फिर आप एक डेवलपर के रूप में आप या तो 1000 वास्तविक वस्तुओं को ला सकते हैं, जैसे मैकबुक प्रो, गूगल नेक्सस, एक केला, एक iPad आदि इसके सामने और परीक्षण करें और देखें कि क्या यह सब काम करता है।
लेकिन आप नकली वस्तुओं का भी उपयोग कर सकते हैं, जैसे एक समान दिखने वाली मैकबुक प्रो (बिना किसी वास्तविक आंतरिक भाग के) या उसके सामने एक प्लास्टिक केला। आप 1000 असली लैपटॉप में निवेश करने और केले को सड़ने से बचा सकते हैं।
मुद्दा यह है कि आप परीक्षण करने की कोशिश नहीं कर रहे हैं कि केला नकली है या नहीं। न ही यह परीक्षण करना कि लैपटॉप नकली है या नहीं। यदि आप एक बार एक मशीन को केले की तरह देखते हैं not an electronic deviceऔर मैकबुक प्रो के लिए कहते हैं, तो यह सब आप परीक्षण कर रहे हैं Laptop, Apple। मशीन के लिए, इसके पता लगाने का परिणाम नकली / नकली इलेक्ट्रॉनिक्स और वास्तविक इलेक्ट्रॉनिक्स के लिए समान होना चाहिए
ऊपर उल्लिखित तर्क वास्तविक कोड के यूनिट-परीक्षण पर भी लागू होता है। यह एक फ़ंक्शन है जिसे आपको वास्तविक इनपुट (और इंटरैक्शन) या नकली से प्राप्त वास्तविक मूल्यों के साथ काम करना चाहिएमान जो आप इकाई-परीक्षण के दौरान इंजेक्ट करते हैं। और जैसे आप यूनिट-टेस्ट (और मॉकिंग) के साथ वास्तविक केले या मैकबुक का उपयोग करने से खुद को कैसे बचाते हैं, आप अपने आप को कुछ ऐसा करने से बचाते हैं जिससे आपका सर्वर 500, 403, 200 आदि का स्टेटस कोड वापस कर देता है। 500 को ट्रिगर करने के लिए आपका सर्वर केवल तभी होता है जब सर्वर डाउन होता है, जबकि 200 तब होता है जब सर्वर ऊपर होता है। 100 नेटवर्क केंद्रित परीक्षणों को चलाना मुश्किल हो जाता है यदि आपको सर्वर के ऊपर और नीचे स्विच करने के बीच लगातार 10 सेकंड इंतजार करना पड़ता है)। इसलिए इसके बजाय आप स्टेटस कोड 500, 200, 403 आदि के साथ प्रतिक्रिया को इंजेक्ट / मॉक करते हैं और इंजेक्शन / नकली मान के साथ अपनी यूनिट / फ़ंक्शन का परीक्षण करते हैं।
कोडिंग उदाहरण:
मान लीजिए कि आप एक iOS एप्लिकेशन लिख रहे हैं और आपके पास नेटवर्क कॉल है । आपका काम आपके आवेदन का परीक्षण करना है। यह जांचने / पहचानने के लिए कि क्या नेटवर्क कॉल अपेक्षित रूप से काम करता है या नहीं, आपकी जवाबदेही नहीं है। यह परीक्षण करने के लिए एक अन्य पार्टी (सर्वर टीम) की जिम्मेदारी है। आपको इस (नेटवर्क) निर्भरता को दूर करना होगा और फिर भी अपने सभी कोड का परीक्षण करना जारी रखना चाहिए जो इसके आसपास काम करता है।
एक JSON प्रतिक्रिया के साथ एक नेटवर्क कॉल विभिन्न स्थिति कोड 404, 500, 200, 303 आदि वापस कर सकता है।
आपका ऐप उन सभी के लिए काम करने के लिए माना जाता है (त्रुटियों के मामले में, आपके ऐप को अपनी अपेक्षित त्रुटि फेंकनी चाहिए)। आप जो मजाक उड़ाते हैं, क्या आप 'काल्पनिक-वास्तविक के समान' नेटवर्क प्रतिक्रियाएं बनाते हैं (जैसे JSON फ़ाइल के साथ 200 कोड) और वास्तविक नेटवर्क कॉल करने और अपने नेटवर्क की प्रतिक्रिया की प्रतीक्षा किए बिना अपने कोड का परीक्षण करें । आप सभी प्रकार के नेटवर्क प्रतिक्रियाओं के लिए मैन्युअल रूप से हार्डकोड / नेटवर्क प्रतिक्रिया लौटाते हैं और देखते हैं कि आपका ऐप आपकी अपेक्षा के अनुरूप काम कर रहा है या नहीं। (आप कभी भी गलत डेटा के साथ 200 का अनुमान / परीक्षण नहीं करते हैं, क्योंकि यह आपकी ज़िम्मेदारी नहीं है, आपकी ज़िम्मेदारी आपके ऐप को एक सही 200 के साथ परीक्षण करना है , या 400, 500 के मामले में, आप परीक्षण करते हैं कि क्या आपका ऐप सही त्रुटि फेंकता है)
यह काल्पनिक-वास्तविक के समान है जिसे मॉकिंग के रूप में जाना जाता है।
ऐसा करने के लिए, आप अपने मूल कोड का उपयोग नहीं कर सकते (आपके मूल कोड में पूर्व-सम्मिलित प्रतिक्रियाएं नहीं हैं, ठीक है?)। आपको इसमें कुछ जोड़ना होगा , उस डमी डेटा को इंजेक्ट / इंसर्ट करना होगा जिसकी सामान्य रूप से आवश्यकता नहीं है (या आपकी कक्षा का एक हिस्सा)।
तो अगर आप एक उदाहरण मूल वर्ग बना सकते हैं और जोड़ने के जो भी आप यह करने की जरूरत है और फिर परीक्षण (यहाँ नेटवर्क HttpResponse, डेटा या विफलता के मामले में किया जा रहा है, तो आपको सही ErrorString, HttpResponse पारित) मज़ाक उड़ाया वर्ग।
लंबी कहानी छोटी, मज़ाक करना आसान है और सीमित करें कि आप क्या परीक्षण कर रहे हैं और आपको यह भी खिलाता है कि कक्षा क्या निर्भर करती है। इस उदाहरण में आप नेटवर्क कॉल का परीक्षण करने से बचते हैं , और इसके बजाय परीक्षण करते हैं कि आपका ऐप काम करता है या नहीं, जैसा कि आप इंजेक्ट किए गए आउटपुट / प्रतिक्रियाओं के साथ उम्मीद करते हैं - - मॉकिंग क्लासेस द्वारा
कहने की जरूरत नहीं है, आप प्रत्येक नेटवर्क प्रतिक्रिया का अलग से परीक्षण करते हैं।
अब एक सवाल जो मेरे दिमाग में हमेशा था, वह था: अनुबंध / अंतिम बिंदु और मूल रूप से मेरे एपीआई की JSON प्रतिक्रिया लगातार अपडेट होती रहती है। मैं यूनिट परीक्षण कैसे लिख सकता हूं जो इसे ध्यान में रखते हैं?
इस पर और अधिक विस्तार करने के लिए: मान लें कि मॉडल को नाम की एक कुंजी / फ़ील्ड की आवश्यकता है username। आप इसे टेस्ट करते हैं और आपका टेस्ट पास हो जाता है। 2 सप्ताह बाद बैकएंड कुंजी का नाम बदल देता है id। आपके परीक्षण अभी भी गुजरते हैं। सही? या नहीं?
क्या मोक्स को अपडेट करने के लिए बैकएंड डेवलपर की जिम्मेदारी है। क्या यह हमारे समझौते का हिस्सा होना चाहिए कि वे अपडेटेड मोक्स प्रदान करें?
उपरोक्त समस्या का उत्तर यह है कि: एक ग्राहक-पक्ष डेवलपर के रूप में इकाई विकास + आपकी विकास प्रक्रिया को पुराने नकली प्रतिक्रिया को पकड़ना / पकड़ना चाहिए। अगर आप मुझसे पूछें कि कैसे? अच्छी तरह से जवाब है:
अपडेट किए गए API का उपयोग किए बिना हमारा वास्तविक ऐप विफल हो जाएगा (या अभी तक असफल व्यवहार नहीं है) ... इसलिए यदि वह विफल रहता है ... तो हम अपने विकास कोड में बदलाव करेंगे। जो फिर से हमारे परीक्षणों को विफल करता है .... जिसे हमें इसे सही करना होगा। (वास्तव में अगर हमें टीडीडी प्रक्रिया को सही तरीके से करना है तो हमें क्षेत्र के बारे में कोई भी कोड नहीं लिखना है जब तक कि हम इसके लिए परीक्षण न लिखें ... और इसे विफल देखें और तब जाकर इसके लिए वास्तविक विकास कोड लिखें।)
यह सब मतलब है कि बैकएंड को यह कहने की ज़रूरत नहीं है: "अरे हमने मक्स को अपडेट किया" ... यह अंततः आपके कोड विकास / डिबगिंग के माध्यम से होता है। क्योंकि यह सभी विकास प्रक्रिया का हिस्सा है! यद्यपि यदि बैकएंड आपके लिए नकली प्रतिक्रिया प्रदान करता है तो यह आसान है।
इस पर मेरा पूरा कहना यह है कि (यदि आप अपडेट की गई एपीआई प्रतिक्रिया को स्वचालित रूप से अपडेट नहीं कर सकते हैं तो) कुछ मानव संपर्क की आवश्यकता है यानी जेएनएस के मैनुअल अपडेट और यह सुनिश्चित करने के लिए छोटी बैठकें करना कि उनके मूल्य आपकी प्रक्रिया का हिस्सा बन जाएंगे।
यह खंड हमारे कोकोहाइड मीटअप समूह में एक सुस्त चर्चा के लिए धन्यवाद लिखा गया था
केवल iOS देवों के लिए:
मॉकिंग का एक बहुत अच्छा उदाहरण नताशा मुर्सचेव की यह प्रैक्टिकल प्रोटोकॉल-ओरिएंटेड बात है । बस 18:30 मिनट पर छोड़ें, हालांकि स्लाइड वास्तविक वीडियो के साथ सिंक से बाहर हो सकते हैं
मुझे वास्तव में प्रतिलेख से यह हिस्सा पसंद है:
क्योंकि यह परीक्षण कर रहा है ... हम यह सुनिश्चित करना चाहते हैं कि getफ़ंक्शन Gettableको कहा जाता है, क्योंकि यह वापस आ सकता है और फ़ंक्शन सैद्धांतिक रूप से कहीं से भी खाद्य पदार्थों की एक सरणी असाइन कर सकता है । हमें यह सुनिश्चित करने की आवश्यकता है कि इसे कहा जाता है;