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