TSA शैली परीक्षण

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

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

“ लेकिन क्या परीक्षण में गलत है, फिल, क्या आप नहीं चाहते कि आपका कोड सुरक्षित हो? यदि हम उत्पादन में आने से पहले एक और बग पकड़ लेते हैं, तो क्या यह इसके लायक नहीं है? "ओह, कोई बकवास नहीं, यह इसके लायक नहीं है, और मुझे फिल नहीं कहते हैं। इस तरह के तर्क के कारण, हमें टीएसए मिला और उन्होंने अंडों को जब्त करने और घुटनों को जब्त करने में अरबों का विलय कैसे किया।

अनुवादक का नोट: टीएसए - परिवहन सुरक्षा प्रशासन - अमेरिकी परिवहन सुरक्षा प्रशासन, जो वे खोजों (विशेषकर हवाई अड्डों पर) के दौरान अपने अभूतपूर्व सावधानी के लिए जमकर घृणा करते हैं।

टेस्ट फ्री नहीं हैं।

आपके द्वारा लिखे गए कोड की प्रत्येक पंक्ति की एक कीमत है। इसे लिखने में समय लगता है, इसे अपडेट करने में समय लगता है, इसे पढ़ने और समझने में समय लगता है। तदनुसार, इसे लिखने का लाभ इसके मूल्य से अधिक होना चाहिए। अति-परीक्षण के मामले में, यह निश्चित रूप से ऐसा नहीं है।

इसे इस तरह से सोचें: बग को रोकने की कीमत क्या है? अगर आपको बॉब को गलती से " वैरिडेट्स_प्रेसेंस_ऑफ: नाम " की लाइन हटाने के लिए टेस्ट की 1000 लाइनें लिखने की आवश्यकता है, तो क्या यह इसके लायक है? स्वाभाविक रूप से नहीं (हाँ, हाँ, यदि आप मंगल पर एक मिसाइल प्रक्षेपण नियंत्रण प्रणाली पर काम कर रहे हैं और रॉकेट व्हाइट हाउस के लिए उड़ जाएगा, यदि आप इसे एक नाम देना भूल जाते हैं, तो आप इसका परीक्षण कर सकते हैं - लेकिन यह आपका मामला नहीं है, इसलिए इसे भूल जाएं)।

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

सात "नहीं" टेस्ट

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

1. 100% परीक्षण कवरेज के लिए प्रयास न करें;
2. कोड का अनुपात 1: 2 से ऊपर के परीक्षणों में पहले से ही बदबू आ रही है, 1: 3 से ऊपर - यह बदबू आ रही है;
3. यदि परीक्षण आपके समय का 1/3 से अधिक लेता है, तो सबसे अधिक संभावना है कि आप इसे गलत कर रहे हैं; यदि परीक्षण में आपका आधे से अधिक समय लगता है, तो आप निश्चित रूप से इसे गलत कर रहे हैं;
4. मानक संघों, मान्यताओं और ActiveRecord osprey का परीक्षण न करें;
5. व्यक्तिगत तत्वों के संयोजन के दौरान उत्पन्न होने वाली समस्याओं के लिए एकीकरण परीक्षणों को बचाएं (यानी उन चीजों के लिए एकीकरण परीक्षण का उपयोग न करें जिनके लिए इकाई परीक्षण का उपयोग किया जा सकता है);
6. जब तक आप गैर-प्रोग्रामर-परीक्षण लेखकों के जादू राज्य में नहीं रहते हैं (या अगर आप अभी भी वहां हैं, तो मुझे जादू की धूल की एक बोतल भेजें!) खीरे का उपयोग न करें।
7. प्रत्येक नियंत्रक, मॉडल या टेम्पलेट के लिए पहले एक परीक्षण लिखने के लिए अपने आप को मजबूर न करें (मेरा सामान्य अनुपात पहले परीक्षणों का 20% है और बाद में 80% परीक्षण)।

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

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

केंट बेक के बुद्धिमान शब्दों में , वह व्यक्ति जिसने परीक्षण के माध्यम से विकास के विकास में सबसे अधिक योगदान दिया:

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