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