परीक्षण प्रेरित डिजाइन - पहला कार्यान्वयन अनुभव

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

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

गीतात्मक विषयांतर। परीक्षणों की भूमिका के बारे में

यूनिट परीक्षणों का उपयोग करने की उपयोगिता के बारे में कई लेख लिखे गए हैं, लेकिन कई प्रतियां उनकी आवश्यकता के बारे में विवादों में टूट गई हैं। और, इस तथ्य के बावजूद कि मैं काफी समय से लेखन और नियमित रनिंग यूनिट परीक्षण का अभ्यास कर रहा हूं, लंबे समय तक मैं उनके उपयोग के लिए स्पष्ट रूप से स्पष्ट नहीं कर सका।
व्यापक स्वचालित परीक्षण के खिलाफ मुख्य तर्क अतिरिक्त समय बिताया लेखन परीक्षण है। दरअसल, स्वचालित परीक्षण अन्य प्रकार के परीक्षण को प्रतिस्थापित नहीं करता है। दृष्टिकोण व्यापक है: "हम एक कार्यक्रम लिखते हैं और इसे परीक्षकों (या यहां तक ​​कि ग्राहक को तुरंत!) को भेजते हैं। यदि त्रुटियां पाई जाती हैं, तो हम उन्हें ठीक कर देंगे और सही किए गए संस्करण को भेज देंगे, और इसी तरह। ” और इस तरह के एक दृष्टिकोण को "बनाया और भुला दिया गया" स्थिति में उचित ठहराया जा सकता है - जब बनाए गए कार्यक्रम को कभी भी समाप्त नहीं करना होगा, फिर से बनाना।

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

हर बार एक सवाल उठता है कि क्या लिखना है या नहीं लिखना है, अपने आप को मंत्र दोहराएं:
"परीक्षण कोड के अतिरिक्त नहीं है, लेकिन इसका महत्वपूर्ण हिस्सा है । "

समस्या का बयान

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

- हाँ, यह ड्रॉपबॉक्स है! - आप कहते हैं।
हां, इन उद्देश्यों के लिए, क्लाउड स्टोरेज का उपयोग किया जा सकता है, यदि कुछ नहीं लेकिन:
1. फाइलें थोड़ी गोपनीय होती हैं; ग्राहक उन्हें क्लाउड पर अपलोड करने से कतराते हैं
2. फ़ाइल स्थानांतरण को विस्तार से लॉग इन किया जाना चाहिए ताकि प्राप्त करने वाला पक्ष यह न कह सके कि "क्या कोई लड़का फ़ाइल था?"

जादू के रूप में, यह एक ऐसी सेवा का उपयोग करने वाला है जो एक डिस्क पर एक फ़ोल्डर में परिवर्तन को ट्रैक करता है और प्राप्तकर्ता कंप्यूटर पर चलने वाली वेब सेवा को सभी नई फाइलें भेजता है। प्रत्येक सफल और असफल ट्रांसमिशन प्रयास को लॉग इन करना होगा। इसके अलावा, लॉगिंग प्रेषक और प्राप्तकर्ता दोनों द्वारा किया जाता है।
WCF और IIS का उपयोग अतिरिक्त आवश्यकताओं के रूप में मौजूद है, लेकिन यह इतना दिलचस्प नहीं है।

हम वास्तुकला डिजाइन करते हैं

हम माथे पर फैसला लेते हैं

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



लॉगिंग घटकों का पुन: उपयोग किया जा सकता है - जो बहुत सुखदायक है। सब कुछ सरल और स्पष्ट है, हम कीबोर्ड लेते हैं, जल्दी से एक परियोजना बनाते हैं ...

स्टॉप स्टॉप स्टॉप। लेकिन टीडीडी का क्या? खैर, आइए सोचते हैं कि हम इस तरह के कार्यक्रम का परीक्षण कैसे करेंगे। और, वास्तव में, केवल एक ही तरीका है - लिखना, दौड़ना और देखना कि क्या होता है। और त्रुटियों का पता लगाने के लिए उन्हें साफ करें। यानी कार्यक्रम लिखने का एक त्वरित और आसान तरीका हमें विकास के "क्लासिक" तरीके की ओर ले जाता है।

और अब चलो जल्दी नहीं है

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



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

हम परीक्षण और कार्यक्रम लिखते हैं

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

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

[TestMethod] void test_that_failed_transfer_logs() { //  var mock = new MockRepository(); var writerMock = mock.StrictMock<IFileReceiver>(); var logMock = mock.StrictMock<INoDateLogger>(); //   var exception = new InvalidOperationException("transfer failed"); Expect.Call(() => writerMock.Receive(fileName, fileData)).Throw(exception); Expect.Call(() => logMock.WriteEvent(FileTransferEvent.Send, fileName, FileTransferStatus.Failed, MessageFormatter.AttemptFailed(1, exception))); mock.ReplayAll(); //  var sender = new FileSender (writerMock, logMock); sender.SendFile(fileName, fileData); //   mock.VerifyAll(); } 

प्रोग्राम चलाएं

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

हम कार्य को जटिल करते हैं - हम एक वेब सेवा से जुड़ते हैं। IIS को तैनात करने, सेवा को कॉन्फ़िगर करने और कॉन्फ़िगर करने में कुछ घंटों का समय लगता है। एक और 25 मिनट लिखने और एक वर्ग को जोड़ने के लिए जो वेब सेवा के लिए रिसीवर इंटरफ़ेस को लागू करता है। और, जैसे ही सभी बुनियादी ढांचे की समस्याओं का समाधान किया गया, कार्यक्रम ने काम किया! यानी मुझे वास्तविक परिस्थितियों में लिखित कक्षाओं के अप्रत्याशित व्यवहार से कोई समस्या नहीं थी।

और हम निष्कर्ष निकालते हैं

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

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