हर कोई महान परीक्षण करना जानता है

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

पहला संकेत

मैंने कुछ हफ़्ते पहले अंकल बॉब से पहला संकेत सीखा था। मैं उनके एक वीडियो से सीख रहा था, और मैंने निम्नलिखित प्रश्न सुना:

»आप कौन सा टेस्ट पहले लिखेंगे?

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

»कौन सा उत्पादन कोड आप पहले लिखेंगे?

लगभग उसी समय जब वह जवाब दे रहा था कि कौन सा टेस्ट पहले लिखें, मैं खुद ही जवाब दे रहा था: वह जो आपको पहले बिट कोड लिखने के लिए मजबूर करता है।

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

क्या आप नहीं जानते कि टेस्ट लिखना कहाँ से शुरू करें? एक लिखें जो आपको उस कोड को लिखने की अनुमति देता है जिसकी आपको आवश्यकता है। यह सरल है।

विधि

यह पहला संकेत था जो मेरे पास था: हर कोई जानता है कि पहला परीक्षण कैसे लिखना है। ऐसा इसलिए है क्योंकि हर किसी के पास पहले से ही यह करने का कौशल है: प्रत्येक अनुभवी प्रोग्रामर जानता है कि कोडिंग कैसे शुरू करें, इसलिए हर कोई जानता है कि कोड का पहला हिस्सा कौन सा है, इसलिए, पहले क्या परीक्षण करना है।

तो, क्या यह संभव है कि हर कोई जानता है कि किसी भी मामले में अच्छे परीक्षण कैसे करें?

चरण 1: पहले परीक्षण

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

चरण 2: बड़े कोड को स्केल करना

यदि आपके पास पहले से ही एक व्यापक आवेदन है, या आप बग की खोज करते हैं तो क्या होगा? यदि आपके पास परीक्षण करने में सहायता के लिए व्यापक आधार नहीं है तो क्या होता है?

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

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

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

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

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

क्या आप एक एपीआई विकसित कर रहे हैं? कोई UI शामिल नहीं है मैंने आपको शर्त लगाई है कि आप पोस्टमैन या इसी तरह के उपकरण का उपयोग मैन्युअल रूप से परीक्षण करने के लिए कर रहे हैं। अपने टेस्ट में भी ऐसा ही करें। MockMCV, Supertest, या आपके सॉफ़्टवेयर स्टैक में उपलब्ध किसी भी उपकरण का उपयोग करें। क्या एपीआई आपके परीक्षण से सीधे कॉल करता है और परिणाम पढ़ता है। और हां, क्या मैं सही हूं जब मैं कहता हूं कि आप जांच नहीं करते हैं कि प्रतिक्रिया में हर क्षेत्र ठीक है? अपने परीक्षण में ऐसा न करें। स्नैपशॉट, या समान के बजाय, Jsonpath जैसे टूल का उपयोग करें, केवल उन फ़ील्ड और मानों की जांच करें जो आपके परीक्षण के लिए प्रासंगिक हैं।

हर समय अपने डिबगिंग कौशल से चिपके रहने की कोशिश करें; हम जितना समझ पाते हैं उससे अधिक अनुभवी होते हैं। उस ज्ञान का लाभ उठाएं और अपना कोड बनाएं जो आप मैन्युअल रूप से करते हैं, वह और अधिक नहीं, कम नहीं।

चरण 3: UI के संदर्भ निकालें

यह थोड़ा पेचीदा लगता है क्योंकि शुरुआत में यह स्वाभाविक नहीं लगता है, लेकिन यह बिल्कुल विपरीत है।

स्टेप 2 की रेसिपी कहती है कि आपको मैन्युअल रूप से जो करना है उसे पुन: पेश करना चाहिए। और संदेह के बिना, आप यूआई का उपयोग कर रहे हैं। तो, UI का संदर्भ हटाने का क्या मतलब है?

थोड़ा आत्म-प्रतिबिंब। जब आप यूआई के साथ बातचीत करते हैं तो आप क्या सोचते हैं? क्या आपको लगता है: मैं उस फ़ील्ड पर क्लिक करने जा रहा हूँ, उन कुंजियों को टाइप करूँगा, और खोज बटन को धकेलूँगा? या आप सोचते हैं: मैं उस खोज को करने जा रहा हूं? दूसरा वाला, सही? वही आपको करना है।

यूआई में टेस्ट डायरेक्ट कॉल में लिखने के बजाय, जो आप सोचते हैं उसे व्यक्त करने के लिए एक लाइब्रेरी या एक इंटरफ़ेस बनाएं। फ़ंक्शन कॉल लिखें: खोज, UI को हेरफेर करने के बजाय। और फिर फ़ंक्शन में सटीक व्यवहार को लागू करें।

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

चरण 4: रिफ्लेक्टर

यह सब कुछ refactor नहीं है; यह सिर्फ चीजों को पढ़ने के लिए आसान बनाए रखता है। लेकिन टेस्ट कोड सबसे ज्यादा।

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

यह कहने की आवश्यकता नहीं है कि उत्पादन कोड की तुलना में परीक्षण कोड क्लीनर और समझने में आसान होना चाहिए।

चरण 5: व्यापार मूल्य मत भूलना

यदि आप चरण 2 (आपको चाहिए) का पालन करते हैं, तो आप देखेंगे कि हम कई छोटी चीजों के लिए बहुत सारे परीक्षण बनाते हैं।

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

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

हमारा उद्देश्य क्या है? यह कुछ कार्यक्षमता को लागू करने के लिए है। हमें एक कार्यक्षमता को लागू करना होगा जो व्यावसायिक मूल्य देता है। हमारे परीक्षण को दिखाना होगा कि कौन सी कार्यक्षमता है और यह कैसे काम करती है। हमें अपने परीक्षण से पढ़ने, समझने और याद रखने में सक्षम होना चाहिए। प्रत्येक परीक्षण को सीधे प्रतिबिंबित करना चाहिए कि यह कौन सा व्यावसायिक मूल्य देता है।

अतिरिक्त चरण: तालिकाओं का उपयोग करें

लगभग सभी परीक्षण ढांचे तालिकाओं को स्वीकार करते हैं। वे काम कर रहे हैं। उनके एपीआई को जानें और उनका उपयोग करें।

वे इतना काम क्यों कर रहे हैं? क्योंकि जब आपके पास एक कोड होता है जो एक मामले का परीक्षण करता है, तो आप तालिका में पंक्तियों को जोड़कर अधिक मामले जोड़ सकते हैं। केवल एक परीक्षण कोड के साथ, आप दसियों मामलों को संभाल सकते हैं। वे बनाए रखने के लिए और उस रखरखाव को पढ़ने के लिए आसान है। अपने टेस्‍ट को रिफलेक्‍टर करने में संदेह न करें क्‍योंकि वे कई तालिकाओं को सम्‍मिलित करते हैं।

निष्कर्ष

महान परीक्षण करना केवल आत्मनिरीक्षण का विषय है। जानें कि आप चीजों को मैन्युअल रूप से कैसे परखते हैं, आप कुछ चरणों का पालन क्यों करते हैं, और कोई अन्य नहीं। फिर, उन्हें स्वचालित करें।

आपके लिए परीक्षण कोड काम करें।