मेरे परीक्षण कवरेज का क्या हुआ?

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

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

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

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

आपको कोई निर्णय नहीं लेना चाहिए

अगर आप अपने कीबोर्ड पर बैठकर निर्णय का प्रयास कर रहे हैं क्या थोड़े से कोड का परीक्षण करने की आवश्यकता है, आप पहले से ही गलत रास्ते पर जा रहे हैं। आपको हमेशा "इसका परीक्षण करें!" यहां तक ​​​​कि अगर यह बहुत मामूली टोन परीक्षण लगता है, तो परीक्षण लिखें।

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

लेकिन आप अधिक परीक्षण नहीं करना चाहते

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

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

class Cart
  def initialize(item_params)
    @line_items = Array(item_params).map {|item| LineItem.new(item[:name], item[:price])}
  end

  def total
    @line_items.sum(&:price)
  end
end

यह वास्तव में ऐसा लगता है कि यहां कोड को Cart दोनों का परीक्षण करने की आवश्यकता है क्लासऔर LineItem कक्षा। लेकिन क्या LineItem . है किसी और चीज द्वारा उपयोग की जाने वाली कक्षा? अगर यह केवल Cart का कार्यान्वयन विवरण है , और बाहरी दुनिया से अवगत नहीं है, इसके लिए वास्तव में कितने परीक्षणों की आवश्यकता है? क्या इसका परीक्षण केवल के माध्यम से नहीं किया जा सकता है आपका Cart कक्षा?

रीफैक्टरिंग द्वारा निकाले गए वर्गों को अक्सर अपने स्वयं के परीक्षण सूट की आवश्यकता नहीं होती है। वे केवल एक कार्यान्वयन विवरण हैं। केवल जब उनका स्वयं उपयोग किया जाता है तो उन्हें उन अतिरिक्त परीक्षणों की आवश्यकता होती है।

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

टेस्ट-ड्रिवेन डेवलपमेंट के साथ अपनी टेस्ट लागतों का परिशोधन करें

पहले खंड में, आपने सीखा कि आपको हर चीज का परीक्षण करना चाहिए। दूसरे खंड में, आपने सीखा कि आपको केवल सार्वजनिक इंटरफेस का परीक्षण करना चाहिए। यह परीक्षण-संचालित विकास है जो इन दो विरोधी लक्ष्यों को एक साथ लाता है।

परीक्षण-संचालित विकास के साथ, आपके परीक्षण इस प्रक्रिया का पालन करके आपके कोड के डिज़ाइन और कार्यान्वयन को संचालित करते हैं:

1. एक असफल परीक्षण लिखें जो मानता है कि आपको जो कोड चाहिए वह पहले से ही है।
2. परीक्षा में उत्तीर्ण होने वाले कोड का सरलतम क्रियान्वयन लिखें।
3. दोहराव को दूर करने के लिए रिफैक्टर (या कोड को अधिक अभिव्यंजक बनाना)।
4. परीक्षा फिर से चलाएँ (यह सुनिश्चित करने के लिए कि वे अभी भी उत्तीर्ण हैं)।
5. चरण 1 पर लौटें।

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

यह इतना आसान कभी नहीं होता। लेकिन अभी भी सबसे जटिल कोड का परीक्षण करने के तरीके हैं।

टीडीडी के कुछ साइड बेनिफिट्स हैं:

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

तो मैं कैसे शुरू करूं?

शुरू करना कठिन हिस्सा है! एक बार जब आप परीक्षण-संचालित कोड लिखने की लय में आ जाते हैं, तो इसे रोकना कठिन होता है।

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

जब आपका काम हो जाए, तो मुझे एक ईमेल भेजें और मुझे बताएं कि यह कैसा रहा।

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