उत्पादन कोड से पहले टीडीडी इकाई परीक्षणों के नियमों के अनुसार लिखा जाता है, लेकिन एकीकरण परीक्षणों के बारे में क्या है जो कंक्रीट (गैर-नकली) के बीच अंतःक्रियात्मक वस्तुओं का आदान-प्रदान करता है?
क्या उन्हें यूनिट परीक्षणों से पहले या उत्पादन कोड के बाद सिर्फ "वायरिंग" का परीक्षण करने के लिए लिखा जाना चाहिए?
ध्यान दें कि मैं स्वीकृति या कार्यात्मक परीक्षणों के बारे में बात नहीं कर रहा हूं लेकिन निचले स्तर के एकीकरण परीक्षण।
जवाबों:
Rspec Book , अन्य BDD संसाधनों के बीच, इस तरह एक चक्र का सुझाव देता है:
संक्षेप में, प्रक्रिया है:
While behaviour required
Write an integration test for a specific behaviour
While integration test failing
Write a unit test to fulfil partial behavior
While unit test failing
Write code to make unit test pass
Commit
While refactoring can be done
Refactor
While unit test failing
Write code to make unit test pass
Commit
Push
अस्वीकरण: मेरे मन में कोई संदेह नहीं है कि यह सबसे अच्छा कोड और उत्पाद की ओर जाता है, लेकिन यह समय लेने वाला हो सकता है। डेटा और नियतत्ववाद के आसपास सभी प्रकार की कठिनाइयाँ हैं, जब यह कहने की बात आती है कि एकीकरण परीक्षण हमेशा पास होने चाहिए। यह सभी परिस्थितियों में उचित नहीं है; कभी-कभी आपको दरवाजे से सामान निकालना पड़ता है।
यह कहा, एक आदर्श प्रक्रिया को ध्यान में रखते हुए महान है। यह आपको एक बिंदु देता है जिससे आप समझौता कर सकते हैं।
वास्तविक परियोजना ने मुझे दिखाया कि इकाई परीक्षण और फिर एकीकरण लिखना संभव नहीं है और यहां तक कि विपरीत दिशा भी गलत है :-) इसलिए, मैं आमतौर पर एकीकरण के साथ इकाई परीक्षण लिखता हूं।
क्यूं कर? मुझे लिखने दें कि मैं दोनों प्रकार के परीक्षण कैसे देखता हूं:
यूनिट परीक्षण - विकिपीडिया और सभी जानकारी के अलावा, यूनिट परीक्षण आपको अपना डिज़ाइन संकीर्ण करने , अपने मॉडल, संबंधों को बेहतर बनाने में मदद करते हैं। प्रवाह सरल है: एक बार जब आप नई परियोजना / नया घटक लिखना शुरू करते हैं, तो अधिकांश समय आप किसी प्रकार का PoC बना रहे होते हैं । जब आप किए जाते हैं, तो आपके पास हमेशा लंबी विधियां, लंबी कक्षाएं, गैर-सुसंगत तरीके और कक्षाएं, आदि होते हैं।
यूनिट परीक्षण आपको इन मुद्दों को दूर करने में मदद करते हैं जब आप वास्तविक यूनिट का परीक्षण करते हैं, तो ऊपर वर्णित मॉक (अन्य घटक पर w / o निर्भरता) का उपयोग करके परीक्षण किया जा सकता है। अप्राप्य कोड का मूल संकेत परीक्षणों का बड़ा नकली हिस्सा है क्योंकि आपको कई निर्भरताओं (या स्थितियों) का मज़ाक बनाने के लिए मजबूर किया जाता है।
एकीकरण परीक्षण - सही और कामकाजी परीक्षण आपसे कहते हैं कि आपका नया घटक (या घटक) एक साथ या अन्य घटकों के साथ काम करता है - यह सामान्य परिभाषा है। मैंने पाया है कि एकीकरण परीक्षण ज्यादातर प्रवाह को परिभाषित करने में आपकी मदद करते हैं कि उपभोक्ता पक्ष से अपने घटक का उपयोग कैसे करें ।
यह वास्तव में महत्वपूर्ण है क्योंकि यह कभी-कभी आपसे कहता है कि आपका एपीआई बाहर से कोई मतलब नहीं है।
खैर, एक बार मैंने इकाई परीक्षण और एकीकरण परीक्षण बाद में क्या लिखा?
मुझे अच्छी कक्षाएं, स्पष्ट डिज़ाइन, अच्छे निर्माणकर्ता, छोटे और सुसंगत तरीके, IoC तैयार आदि मिले। एक बार जब मैं अपनी कक्षा / एपीआई कुछ उपभोक्ता को देता हूं, जैसे एकीकरण या GUI टीम से डेवलपर, तो वह मेरे API का उपयोग करने में असमर्थ था क्योंकि यह असंगत लगता है , अजीब। वह सिर्फ उलझन में था। इसलिए मैंने उनके दृष्टिकोण के अनुसार एपीआई की मरम्मत की, लेकिन कई परीक्षणों को फिर से लिखना भी आवश्यक था क्योंकि मुझे तरीकों को बदलने के लिए धक्का दिया गया था और कभी-कभी प्रवाह भी एपीआई का उपयोग कैसे करें।
खैर, एक बार जब मैंने एकीकरण परीक्षण और इकाई परीक्षण लिखे, तब क्या होगा?
मुझे सटीक प्रवाह मिला, अच्छी उपयोगिता। मेरे पास भी बड़ी कक्षाएं, गैर-सुसंगत कोड, कोई लॉगिंग, लंबी विधियां नहीं हैं। स्पेगेटी कोड
मेरी क्या सलाह है?
मैंने निम्न प्रवाह सीखा है:
ध्यान दें कि मैंने इकाई / एकीकरण परीक्षण के बारे में छोटी प्रस्तुति दी है, स्लाइड # 21 देखें जहां कंकाल का वर्णन किया गया है।
यूनिट टेस्ट का उपयोग किसी एप्लिकेशन में सॉफ्टवेयर के सबसे छोटे संभव परीक्षण योग्य बिट का परीक्षण करने और इसकी कार्यक्षमता का परीक्षण करने के लिए किया जाता है। प्रत्येक इकाई को आवेदन के कुछ हिस्सों या बड़े घटकों में समामेलित करने से पहले अलग से परीक्षण किया जाता है।
यह वह जगह है जहाँ एकीकरण परीक्षण आते हैं:
वे इन नए बनाए गए भागों का परीक्षण करते हैं जो इन भागों को एक साथ फिट करने के दौरान पहले से परीक्षण की गई इकाइयों से मिलकर होते हैं। सबसे अच्छा मामला यह होगा कि आप आवेदन लिखते समय इस बिंदु पर परीक्षण लिखेंगे।
मैं एकीकरण परीक्षणों को इकाई परीक्षणों के समान देखता हूं। उसमें मैं एक ब्लैक बॉक्स के रूप में कोड का एक सबसेट मान रहा हूं। इसलिए एकीकरण परीक्षण सिर्फ एक बड़ा बॉक्स है।
मैं उन्हें उत्पादन कोड से पहले लिखना पसंद करता हूं। इससे मुझे यह याद रखने में मदद मिलती है कि कौन से टुकड़े मैंने अभी तक नहीं उतारे हैं या मैंने ऑब्जेक्ट्स इंटरैक्ट में थोड़ा विस्तार किया है।
स्वीकृति परीक्षणों के अलावा, मैं केवल एक आवेदन की सीमाओं पर एकीकरण परीक्षण लिखना चाहता हूं, यह सत्यापित करने के लिए कि यह तीसरे पक्ष के सिस्टम या घटकों के साथ अच्छी तरह से एकीकृत है।
एडेप्टर ऑब्जेक्ट बनाने के लिए विचार यह है कि अनुवाद कैसे तीसरे पक्ष से बोलता है कि आपके आवेदन की क्या आवश्यकता है, और इन अनुवादकों का वास्तविक बाहरी सिस्टम के खिलाफ परीक्षण करें। चाहे आप उस परीक्षण-प्रथम या परीक्षण-अंतिम को करते हैं, क्या मुझे लगता है कि आपकी नियमित इकाई परीक्षणों से कम महत्वपूर्ण है क्योंकि
टीडीडी द्वारा प्रदान की गई डिजाइन अंतर्दृष्टि यहां बहुत मायने नहीं रखती है क्योंकि डिजाइन बहुत पहले से जाना जाता है और इसमें आमतौर पर कुछ भी जटिल नहीं होता है, आप बस चीजों को एक सिस्टम से दूसरे में मैप करते हैं।
जिस मॉड्यूल / सिस्टम से आप निपटना चाहते हैं, उसके आधार पर, इसमें बहुत सारे अन्वेषण, कॉन्फ़िगरेशन टिंकरिंग, सैंपल डेटा तैयार करने की आवश्यकता होती है, जिसमें समय लगता है और एक छोटे टीडीडी फीडबैक लूप में वास्तव में अच्छी तरह से फिट नहीं होता है।
हालाँकि, यदि आप वास्तव में कम सुरक्षित चरणों में अपने एडेप्टर को सहज रूप से बनाने में अधिक सहज महसूस करते हैं, तो मैं निश्चित रूप से परीक्षण-पहले जाने की सलाह दूंगा, यह चोट नहीं पहुँचा सकता है।
आप इस दृष्टिकोण के उदाहरण यहां देख सकते हैं: http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (6 ठी पैरा) http://blog.8thlight.com/eric- स्मिथ / 2011/10/27 / thats-नहीं-yours.html
इसलिए मैं पहला उत्तर स्वीकार करने जा रहा था लेकिन इसे हटा दिया गया है।
इसे जमा करने
के लिए किसी दिए गए पुनरावृत्ति में:
एकीकरण स्तर पर परीक्षण की गारंटी देने के लिए 1 और 2 को ध्यान में रखते हुए एकीकरण परीक्षण का ध्यान रखें।
एकीकरण परीक्षण आवश्यक रूप से चरण 3 पर समाप्त होने के लिए अंत में नहीं लिखे गए हैं वे आंशिक रूप से चरण 1 और 2 के बीच लिखे जा सकते हैं।
इकाई परीक्षण आपके प्रोजेक्ट के भीतर कोड के असतत ब्लॉक का परीक्षण करता है ।
एकीकरण परीक्षण परीक्षण करते हैं कि आपका कोड अन्य कोड के साथ कैसे इंटरफेस करता है: दूसरे शब्दों में, वे आपके कोड के इंटरफ़ेस का परीक्षण करते हैं ।
एक इंटरफ़ेस के पीछे कोड विकसित करते समय इकाई परीक्षण लिखें।
इंटरफ़ेस विकसित करते समय या इंटरफ़ेस को लागू करने वाले किसी भी कोड को एकीकरण परीक्षण लिखें।
इसका मतलब यह है कि आप कभी-कभी किसी परियोजना में बहुत देर से एकीकरण परीक्षण लिखेंगे, क्योंकि अधिकांश कार्य इंटरफ़ेस के पीछे है: उदाहरण के लिए, एक कंपाइलर, एक विशेष वेबसर्विस जो तर्क की कई परतों को लागू करता है या .. कुछ जिसमें बहुत कुछ शामिल होता है आंतरिक तर्क।
हालाँकि, यदि आप REST सेवाओं का एक सेट लागू कर रहे हैं या डेटा मॉडल को फिर से सक्रिय कर रहे हैं और XA लेनदेन के लिए समर्थन जोड़ रहे हैं, तो आप लगभग तुरंत एकीकरण परीक्षण विकसित करने जा रहे हैं, क्योंकि आपका अधिकांश कार्य इंटरफ़ेस के आसपास केंद्रित है, चाहे वह REST API या प्रोग्राम डेटा मॉडल का उपयोग कैसे करता है।