परीक्षण तुच्छ कोड

यहां तक ​​कि अगर कोड तुच्छ है, तो भी आपको इसका परीक्षण करना चाहिए।
कुछ दिनों पहले, रॉबर्ट मार्टिन ने "टीडीडी की प्रगति" नामक एक पोस्ट प्रकाशित की ( यहाँ अनुवाद - अनुवादक के लिए टिप्पणी ) जहां उन्होंने कहा कि उन्होंने बिल्कुल सभी कोड का परीक्षण नहीं किया। असाधारण स्थितियों के बीच जब यह TDD का उपयोग करने लायक नहीं है, अंकल बॉब ने GUI कोड लिखने का उल्लेख किया है, और मैं इस तरह के बयानों में बिंदु को देखता हूं, लेकिन अपवादों के बीच, मेरी राय में, अतार्किक है ।
रॉबर्ट मार्टिन का दावा है कि वह परीक्षण के माध्यम से विकसित नहीं होता है:

• गेटर्स और सेटर;
• सिंगल लाइन फ़ंक्शन;
• बिल्कुल तुच्छ कार्य।

संक्षेप में, ये कथन परीक्षण के माध्यम से "तुच्छ" कोड विकसित करने के लिए केवल नियम को उकसाते हैं, जैसे गेटर्स और सेटर (.NET प्रोग्रामर के लिए गुण)।
इस TDD नियम से जुड़े कई मुद्दे हैं जिन पर मैं चर्चा करना चाहूंगा:

• कारण और प्रभाव का भ्रम है;
• भविष्य में तुच्छ कोड बदल सकता है;
• यह शुरुआती लोगों के लिए भयानक सलाह है।

मुझे इनमें से प्रत्येक बिंदु को अधिक विस्तार से जांचने दें।

कारण संबंध

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

Encapsulation।

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

टीडीडी सीखना

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

मूल कारण विश्लेषण

क्या मैं इस बात पर जोर देता हूं कि आपको सभी गेटर्स और सेटरों पर TDD लागू करना चाहिए? हां, मैं वास्तव में जोर देता हूं।
आप कह सकते हैं कि इस तरह के दृष्टिकोण में बहुत अधिक समय लगेगा। रॉबर्ट मार्टिन ने इस बारे में विडंबना व्यक्त की :

"तेजी से आगे बढ़ने का एकमात्र तरीका सक्षम रूप से आगे बढ़ना है।"

और फिर भी, आइए देखें कि गुणों के लिए टीपीपी का आवेदन कैसा दिखेगा (जावा प्रोग्रामर पढ़ना जारी रख सकते हैं। सी # में गुण गेटर्स और सेटर के लिए सिंटैक्टिक चीनी हैं)।
मान लीजिए कि मेरे पास एक DateViewModel क्लास है और मैं चाहता हूं कि उसके पास वर्ष का प्रतिनिधित्व करने वाली एक इंट प्रॉपर्टी हो। पहला टेस्ट इस तरह होगा:

[Fact] public void GetYearReturnsAssignedValue() { var sut = new DateViewModel(); sut.Year = 2013; Assert.Equal(2013, sut.Year); } 

बिना कुछ लिए और सब कुछ पर संदेह किए, निम्नलिखित सही कार्यान्वयन होगा:

 public int Year { get { return 2013; } set { } } 

टीपीपी के बाद, यह कोड बिल्कुल वैसा ही दिखेगा। अच्छा, चलो एक और परीक्षा लिखें:

 [Fact] public void GetYearReturnsAssignedValue2() { var sut = new DateViewModel(); sut.Year = 2010; Assert.Equal(2010, sut.Year); } 

साथ में, ये दो परीक्षण मुझे संपत्ति को सही ढंग से लागू करने के लिए प्रोत्साहित करते हैं:

 public int Year { get; set; } 

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

 [Theory, AutoWebData] public void YearIsWritable(WritablePropertyAssertion a) { a.Verify(Reflect<DateViewModel>.GetProperty<int>(sut => sut.Year)); } 

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

अनुवादक से: मैं अगली बार कुछ ऑटोफ़िक्चर समीक्षा का अनुवाद जारी करने की योजना बना रहा हूँ , या स्वयं समीक्षा कर रहा हूँ। IMHO, एक बहुत ही दिलचस्प उपकरण।