🧘🏾 🤸🏿 🤚🏾 लोकप्रिय डेवलपर परीक्षण के बारे में सवाल करते हैं 👩🏽 🏴 ⚔️

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

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

लिखने का कारण हालिया लेख “ PHPUnit ” था । डॉकट्रिन एंटिटी मैनेजर को तोड़-मरोड़ कर ”, जिनमें से कुछ पर भी मैं चर्चा करता हूँ।

प्रश्नों की सूची:

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

टेस्ट लिखना है या नहीं लिखना है?

मैंने इस विषय पर बहुत सारी राय देखी, लेकिन मैं अपने दम पर आया: मुझे व्यवसाय की जरूरतों पर ध्यान देने की आवश्यकता है।

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

परीक्षण के लाभ, संक्षेप में और सार:

जल्दी पता लगाने के कारण बग को ठीक करने की लागत में एक महत्वपूर्ण कमी।
संविदा तय करना।
निम्न स्तर का प्रलेखन।
वास्तु समस्याओं का पता लगाना।

इसलिए यदि आपकी परियोजनाएं कई फाइलों से एकमुश्त स्क्रिप्ट नहीं हैं, तो मैं निश्चित रूप से परीक्षण लिखने की सलाह देता हूं। इसलिए, शीर्षक से प्रश्न का सुधार किया जाना चाहिए: "किस हद तक परीक्षण लिखे जाने चाहिए, और कौन से हैं?" इसके बारे में आगे।

और अगर समय परीक्षण के लिए आवंटित नहीं किया गया है?

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

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

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

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

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

परीक्षण के प्रकार, कैसे चुनें?

माइकल कोहेन परीक्षण पिरामिड

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

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

हमेशा जहाँ संभव हो इकाई परीक्षण लिखने की कोशिश करें, लेकिन परीक्षण करने के लिए क्या बेकार है यह परीक्षण न करें।

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

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

मेरे लिए लंबे समय तक परीक्षण लिखना क्यों मुश्किल है?

कभी-कभी परीक्षण लिखना मुश्किल होता है क्योंकि कोड उनके लिए तैयार नहीं होता है। भीड़ का ढेर, जहां उनमें से कुछ दूसरों को देते हैं, वे भी एक परिणाम हैं।

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

प्रथम श्रेणी कोड जैसे परीक्षणों का व्यवहार करें, व्यावसायिक तर्क के समान उच्च गुणवत्ता कोड का निरीक्षण करें। खराब परीक्षण कोड गुणवत्ता समय के साथ उत्पादकता कम करेगी।

निजी तरीकों का परीक्षण कैसे करें?

कोई रास्ता नहीं। हम एक अनुबंध का परीक्षण कर रहे हैं - मॉड्यूल द्वारा अन्य मॉड्यूल को प्रदान किया गया इंटरफ़ेस। हमें आंतरिक कार्यान्वयन का परीक्षण करने की आवश्यकता नहीं है, यह बदल सकता है।

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

एकीकरण परीक्षण कैसे लिखें? आधार का परीक्षण कैसे करें?

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

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

कैसे करें: एकीकरण या कार्यात्मक?

एकीकरण परीक्षण अलगाव के संदर्भ में परीक्षण स्तरों में से एक है। कार्यात्मक परीक्षण - अनुपालन परीक्षण। ये परिभाषा विभिन्न विमानों पर पड़ी है, और आप उनके बीच एक समान चिन्ह नहीं रख सकते हैं, लेकिन डेवलपर्स के बीच बातचीत में व्यवहार में उनका मतलब एक ही बात से है, हालांकि यह सही नहीं है।

बाहरी निर्भरता के साथ क्या करना है?

हम बाहरी निर्भरता को मोकी से बदलते हैं। न केवल इकाई परीक्षणों के लिए, बल्कि एकीकरण परीक्षणों के लिए भी।

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

परीक्षण और परीक्षण विषय के बीच नेविगेशन को सरल कैसे करें?

यदि आप नामकरण मानकों का उपयोग करते हैं तो आधुनिक विकास उपकरण परीक्षणों या परीक्षण कक्षाओं के स्थान को ट्रैक कर सकते हैं। नेविगेशन में आसानी के लिए, आप JetBrains उत्पादों में कीबोर्ड शॉर्टकट Ctrl + Shift + T का उपयोग कर सकते हैं, इसके अलावा, यदि परीक्षण मौजूद नहीं है, तो आपको इसे बनाने और वायरफ्रेम बनाने के लिए प्रेरित किया जाएगा।

कभी-कभी आपको परीक्षण के विषय के लिए कई अलग-अलग परीक्षण कक्षाओं या विधियों की आवश्यकता होती है, इस मामले में आपको आईडीई की मदद करने की आवश्यकता होती है, उदाहरण के लिए, PHPUnit के मामले में @covers एनोटेशन जोड़ें।

क्या मुझे TDD का उपयोग करना चाहिए?

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

कोड को बेहतर बनाने के लिए और क्या इस्तेमाल किया जा सकता है?

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

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

लोकप्रिय डेवलपर परीक्षण के बारे में सवाल करते हैं