.NET में उदाहरणों के साथ यूनिट टेस्टिंग की कला बुक करें

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



यह किताब करीब डेढ़ साल पहले लिखी गई थी। मैंने इसे दुर्घटना से नहीं चुना था, यहां तक ​​कि php प्रोग्रामर भी इसकी सलाह देते हैं , हालांकि उसके अधिकांश उदाहरण C # में लिखे गए हैं। और जब से मैंने इस विशेष पुस्तक को पढ़ने के लिए पर्याप्त अलग-अलग सिफारिशें देखीं, मैंने निरक्षरता को समाप्त करने के लिए इसके साथ शुरुआत करने का फैसला किया।



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



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



तो किताब किस बारे में है? हमेशा की तरह, पुस्तक की आधिकारिक वेबसाइट पर पुस्तक के साथ परिचित होने के लिए कुछ अध्यायों को डाउनलोड करने का अवसर है: यह मूल्यांकन करने के लिए कि यह आपके अनुरूप है या नहीं। जहां तक ​​मुझे पता है, इसका रूसी में अनुवाद नहीं किया गया है, और जब से इसे जारी किए हुए पर्याप्त समय बीत चुका है, तब तक इनका अनुवाद नहीं किया जाएगा। "नमस्ते दुनिया!" के अध्यायों से किसी भी अन्य की तरह, किताब शुरू होती है, इसके बारे में कि क्या परीक्षण लिखने के लिए, क्या उपकरण, ठीक है, पहला परीक्षण लिखा जाता है। इसके अलावा, लेखक जिन रूपरेखाओं का उपयोग करेगा, उन्हें संक्षेप में वर्णित किया गया है: नुनिट और राइनो मोक्स। राइनो मोक्स पर जोर, जहां तक ​​मैं समझता हूं, लेखक द्वारा बनाया गया था क्योंकि उन्होंने एक बार अपने ब्लॉग पर आंकड़े एकत्र किए थे कि इस ढांचे का उपयोग दूसरों की तुलना में अधिक किया जाता है। यह मुझे लगता है कि स्थिति अब बदल गई है, और अधिक लोकप्रिय ढांचा अभी भी है - यह Moq है । खैर, NUnit एक ही लोकप्रिय परीक्षण ढांचा बना हुआ है। एक समय मैं MbUnit में बदल गया, क्योंकि वहाँ अधिक अवसर थे, लेकिन फिलहाल NUnit को अच्छी तरह से खींच लिया गया और एक प्रतियोगी के साथ पकड़ लिया गया।



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



मुझे अपने पुराने प्रश्न का उत्तर भी मिला। मैंने एक बार एक उदाहरण के रूप में MbUnit का उपयोग करते हुए NHibernate अनुप्रयोगों का परीक्षण करते हुए एक लेख लिखा था, और फिर मुझे एक टिप्पणी मिली:

मेरा एक सवाल है। और क्यों? ORM का परीक्षण क्यों? तो ORM के साथ बातचीत का पूरा टुकड़ा एक अलग वर्ग (अलग वर्गों) में निकाला जाता है, और कुछ IoC कंटेनर का उपयोग किया जाता है।

क्या आप वास्तव में ORM में परीक्षण कर रहे हैं? मानचित्रण? प्रश्नों?

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



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



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



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