आप कहां गए xUnit

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

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

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

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


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

"यह सब बहुत अच्छा है, लेकिन यह इकाई परीक्षणों से कैसे संबंधित है?" एक अधीर पाठक बहुत ही उचित तरीके से पूछेगा। जवाब देने के लिए, कुछ सरल कार्य पर विचार करें। मान लीजिए, उदाहरण के लिए, हम अपने स्मॉलटॉक पर्यावरण से खेल "बैल और गाय" के लिए एक भागीदार बनाना चाहते हैं। आइए एक विशेष ग्राफिकल इंटरफ़ेस के रूप में अधिकता को छोड़ दें और इसे सरलतम तरीके से करने का प्रयास करें। समान कार्यक्षेत्र इसके लिए काफी उपयुक्त है: हम सिस्टम को पहले गेम ऑब्जेक्ट बनाने के लिए कहते हैं, फिर उसे हमारे अनुमान के विकल्प के साथ संदेश भेजते हैं, और गेम एक संकेत देता है (बैल और गायों की संख्या) ... उदाहरण के लिए, एक बिंदु के रूप में: 2 @ 3 (ऑब्जेक्ट 2 एक @ संदेश पैरामीटर 3 साथ भेजा जाता है - परिणामस्वरूप, हमें Point क्लास का एक उदाहरण मिलता है, जहां x = 2 , y = 3 ) का मतलब दो बैल और तीन गायों से होगा; उत्तर 4 @ 0 अर्थ है कि कुंजी बिना खंडित है।

सामान्य योजना तैयार है, हम इसके कार्यान्वयन के लिए आगे बढ़ते हैं। आप इसे उस तरह से विकसित कर सकते हैं जो आमतौर पर किया जाता है: कक्षाएं, उनमें विधियां, आदि बनाकर। लेकिन आप कुछ और कर सकते हैं - बस खेलना शुरू करें:


हम उम्मीद करते हैं कि इसके जवाब में, सिस्टम उस वर्ग का एक ऑब्जेक्ट बनाएगा जिसकी हमें ज़रूरत है। इसे सत्यापित करने के लिए, हम परिणामी वस्तु का निरीक्षण कर सकते हैं। हम निरीक्षण का चयन करते हैं ... मेनू आइटम और सिस्टम चेतावनी प्राप्त करें: यह नहीं जानता कि बुल्सएंडकॉव्स नाम से क्या समझा जाना चाहिए।


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


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


ओके पर क्लिक करें ... और इंस्पेक्टर विंडो देखें जो गेम के बनाए इंस्टेंस के साथ खुलता है।


हमें जो चाहिए था वो हमें मिला। अगला चरण: हम अपने विकल्प के खेल की जानकारी देते हैं।

 game guess: ??? 

यहां हमें सोचना होगा: कल्पना करने के लिए सबसे अच्छा विचार क्या है? सबसे अधिक संभावना है, कुंजी के समान ... लेकिन हमने अभी तक कुंजी को याद नहीं किया है ... मेरे पास "स्वचालित रूप से पैदा हुए" तीन विकल्प हैं: 1) अनुमान लगाने के लिए एक विशेष वर्ग बनाएं, या 2) एक संख्या का उपयोग करें, या 3) एक स्ट्रिंग का उपयोग करें। चुनने के लिए, मुझे सोचना होगा ... मैं अपनी पसंद को लाइन पर रोक देता हूं, क्योंकि (आगे देखते हुए) मैं समझता हूं कि भविष्य में मुझे कुंजी और चरित्र से चरित्र का मिलान करना होगा, और रेखा पात्रों का अनुक्रमित संग्रह है।


दूसरी पंक्ति का निष्पादन एक त्रुटि की ओर जाता है।


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


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


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


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


संकलित किए जाने वाले विधि कोड में परिवर्तन के लिए, उन्हें "स्वीकृत" (स्वीकार) होना चाहिए। उसके बाद, हमारे खेल सत्र के निष्पादन को जारी रखने के लिए आगे बढ़ें बटन पर क्लिक करें ... और हमें अपेक्षित परिणाम मिलेगा।


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

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

“जब मैंने xUnit के पहले संस्करण को डिजाइन करना शुरू किया, तो मैंने अपनी एक सामान्य चाल का उपयोग किया: वस्तुओं में कुछ मोड़ो; इस मामले में, संपूर्ण कार्यक्षेत्र एक वर्ग में बदल गया। प्रत्येक टुकड़े को तब एक विधि (उपसर्ग "परीक्षण" के साथ एक आदिम एनोटेशन के रूप में) द्वारा दर्शाया जाएगा।

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

***

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