TDD के लंदन और शिकागो स्कूल क्या हैं?

Question

मैं लंदन शैली बनाम शिकागो शैली (जिसे कभी-कभी डेट्रॉइट शैली कहा जाता है) टेस्ट ड्रिवेन डेवलपमेंट (टीडीडी) के बारे में सुन रहा हूं।

यूटा चरम प्रोग्रामिंग उपयोगकर्ता समूह की कार्यशाला:

लंदन के एक्सट्रीम मंगलवार क्लब के बाद इंटरैक्शन-स्टाइल टीडीडी को मॉकिस्ट-स्टाइल या लंदन-शैली भी कहा जाता है , जहां यह लोकप्रिय हो गया। यह आमतौर पर डेट्रायट-शैली या क्लासिक टीडीडी के साथ विपरीत है जो अधिक राज्य-आधारित है।

जेसन गोर्मन की कार्यशाला :

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

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

Answer 1

मान लीजिए कि आपके पास "खाता-बही" नामक वर्ग है, जो "गणना" नामक एक विधि है, जो "गणना" करने के लिए पारित किए गए तर्कों के आधार पर "कैलकुलेटर" का उपयोग करता है, उदाहरण के लिए "गुणा (x, y)" या "घटाना" x, y) ”।

अब, मान लीजिए कि जब आप ledger.calculate ("5 * 7") कॉल करते हैं तो क्या परीक्षण करना चाहते हैं।

लंदन / इंटरेक्शन स्कूल ने आपको बताया होगा कि क्या कैलक्यूलेटर। इसके लिए विभिन्न मॉकिंग फ्रेमवर्क उपयोगी हैं, और यह बहुत उपयोगी हो सकता है यदि, उदाहरण के लिए, आपके पास "कैलकुलेटर" ऑब्जेक्ट का स्वामित्व नहीं है (मान लें कि यह एक बाहरी घटक या सेवा है जिसे आप सीधे परीक्षण नहीं कर सकते हैं, लेकिन आप करते हैं पता है कि आपको एक विशेष तरीके से कॉल करना है)।

शिकागो / स्टेट स्कूल ने आपको बताया होगा कि क्या परिणाम 35 है। ऐसा करने के लिए आमतौर पर junit / nUnit रूपरेखा तैयार की जाती है।

दोनों वैध और महत्वपूर्ण परीक्षण हैं।

Comments

बहुत अच्छा उदाहरण है।

— सेवेंससीकैट

मैं प्रत्येक का उपयोग करने के लिए कुछ और कारण जोड़ूंगा: यदि महत्वपूर्ण बात यह निर्धारित कर रही है कि की जा रही कार्रवाई के आधार पर कुछ बदल गया है या नहीं बदला गया है (उदाहरण के लिए, ledger.bucket.value 35 हो रहा है जब ledger.calculate ("5 *) 7 ") कहा जाता है), आप राज्य के सिद्धांतों (शिकागो स्कूल) का उपयोग करना चाहते हैं। यह तब सबसे ज्यादा मददगार होता है, जब आप विधि को कॉल करने से पहले सिस्टम की स्थिति पर पूरा नियंत्रण रखते हैं, और जब आप वास्तव में यह नियंत्रित करते हैं कि विधि क्या करती है।

— मैथ्यू फ्लिन

यदि महत्वपूर्ण चीज यह जान रही है कि एक दूसरी विधि को कहा जाता है (जैसे, कैलक्यूलेटर। कुलीन रूप से (5, 7)), तो आप एक मॉक ऑब्जेक्ट के माध्यम से गतिविधि अभिकथन का उपयोग करना चाहते हैं। यदि विधि को वांछित पक्ष प्रभाव (जैसे डेटा को सहेजना, काउंटर को बढ़ाना, संदेश भेजना, आदि) है यदि आप वास्तव में नियंत्रण नहीं करते हैं कि विधि क्या करती है, तो यह सबसे अधिक उपयोगी है, इसलिए वापसी का मूल्य असंगत हो सकता है । इसके अलावा, यदि आप सिस्टम की स्थिति को आसानी से नियंत्रित नहीं कर सकते हैं, तो सबसे अच्छा आप यह निर्धारित कर सकते हैं कि क्या गतिविधियाँ होती हैं।

— मैथ्यू फ्लिन

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

— केविन

लंदन का दृष्टिकोण भी स्पष्ट प्रतिक्रिया संकेतों को प्रदान करने का तर्क देता है, क्योंकि यदि में Calculatorपुन: प्राप्त होता है multiply, तो आपको दो परीक्षण विफल होंगे: लेज़र परीक्षण और कैलकुलेटर परीक्षण, लेकिन यदि आप कैलकुलेटर को मॉक करते हैं तो केवल एक परीक्षण विफल होता है। इससे बग की उत्पत्ति को इंगित करना आसान हो सकता है, खासकर अगर सिस्टम जटिल है।

— मथायस

Answer 2

मार्टिन फॉलर द्वारा लेख Mocks Arn't Stubs , विषय का अच्छा परिचय है।

आपके द्वारा चुनी गई डिज़ाइन शैली (और आपके द्वारा अपने प्रोग्राम बनाने वाले डिज़ाइन सिद्धांत) के आधार पर, किसी ऑब्जेक्ट को देखने के कम से कम दो तरीके हैं:

1. एक इकाई के रूप में जो इनपुट के आधार पर संगणना करती है। इस गणना के परिणामस्वरूप वस्तु एक मान लौटा सकती है या अपनी स्थिति बदल सकती है।
2. एक सक्रिय तत्व के रूप में जो संदेश पारित करके सिस्टम में अन्य तत्वों के साथ संचार करता है।

पहले मामले में, आप उस चीज में रुचि रखते हैं जो प्रसंस्करण से निकलती है या उस प्रसंस्करण के बाद वस्तु को किस स्थिति में छोड़ दिया जाता है। यह वह जगह है जहां assertEquals()चित्र में प्रवेश करने जैसी विधियां हैं । इस मामले में, यह बहुत मायने नहीं रखता है कि प्रसंस्करण में अन्य ऑब्जेक्ट क्या शामिल थे, किन तरीकों को बुलाया गया था, आदि इस तरह के सत्यापन को राज्य-आधारित सत्यापन कहा जाता है और "शास्त्रीय" शैली है।

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

ध्यान दें कि यह या तो / या विकल्प नहीं है। आपके पास एक डिज़ाइन शैली हो सकती है जो प्रत्येक से सर्वश्रेष्ठ प्राप्त करने के लिए दोनों दृष्टिकोणों को मिलाती है।