उपयोगिता के आधार पर यूनिट परीक्षणों के प्रकार

Question

मूल्य के दृष्टिकोण से मैं अपने अभ्यास में इकाई परीक्षणों के दो समूहों को देखता हूं:

1. परीक्षण जो कुछ गैर-तुच्छ तर्क का परीक्षण करते हैं। उन्हें लिखना (लागू करने से पहले या बाद में) कुछ समस्याओं / संभावित बगों को प्रकट करता है और भविष्य में मामले के तर्क को बदलने में आश्वस्त होने में मदद करता है।
2. परीक्षण जो कुछ बहुत ही तुच्छ तर्क का परीक्षण करते हैं। वे परीक्षण की तुलना में दस्तावेज़ कोड (आमतौर पर नकली के साथ) अधिक पसंद करते हैं। उन परीक्षणों का रखरखाव वर्कफ़्लो "कुछ तर्क नहीं बदला, परीक्षण लाल हो गया - धन्यवाद भगवान मैंने यह परीक्षण लिखा" लेकिन "कुछ तुच्छ कोड बदल गए, परीक्षण गलत नकारात्मक हो गया - मुझे कोई लाभ हासिल किए बिना परीक्षण को फिर से बनाए रखना है" । अधिकांश समय उन परीक्षणों को बनाए रखने के लायक नहीं होते हैं (धार्मिक कारणों को छोड़कर)। और कई प्रणालियों में मेरे अनुभव के अनुसार वे परीक्षण सभी परीक्षणों के 80% की तरह हैं।

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

Comments

मैं ज्ञात (विशिष्ट) बगों के लिए यूनिट परीक्षण जाँच कर रहा हूं - जो एक बार मूल इकाई परीक्षणों के माध्यम से फिसल गया है - एक अलग समूह के रूप में जिसकी भूमिका प्रतिगमन कीड़े को रोकने के लिए है।

— कोनराड मोरावस्की

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

— तेलस्टिन

@Telastyn - आपकी टिप्पणी के बारे में सब कुछ मुझे बिल्कुल पागल लगता है। कौन जानबूझकर कोड बदलना मुश्किल बना देगा? क्यों बदलते कोड से डेवलपर्स को हतोत्साहित करते हैं क्योंकि वे फिट दिखते हैं - क्या आप उन पर भरोसा नहीं करते हैं? क्या वे बुरे डेवलपर हैं?

— बेंजामिन हॉजसन

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

— बेंजामिन हॉजसन

वैसे भी, ओपी को यह ब्लॉग पोस्ट दिलचस्प बनाने के लिए रेल के निर्माता से मिल सकती है। मोटे तौर पर उसकी बात को सरल बनाने के लिए, आपको शायद उन 80% परीक्षणों को दूर फेंकने की कोशिश करनी चाहिए।

— बेंजामिन हॉजसन

Answer 1

मुझे लगता है कि यूनिट टेस्टिंग के दौरान डिवाइड का सामना करना स्वाभाविक है। इसे ठीक से कैसे करें और स्वाभाविक रूप से अन्य सभी राय स्वाभाविक रूप से गलत हैं, इस पर कई अलग-अलग राय हैं । DrDobbs पर हाल ही में कुछ लेख हैं जो इस मुद्दे का पता लगाते हैं जिससे मैं अपने उत्तर के अंत में लिंक करता हूं।

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

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

tl; dr यह परीक्षण गलत होने में आसान है, यह अविश्वसनीय रूप से माना जाता है और मुझे विश्वास नहीं है कि कोई भी एक परीक्षण पद्धति स्वाभाविक रूप से बेहतर है जब तक कि वे संदर्भ के भीतर परिश्रमपूर्वक और पेशेवर रूप से उपयोग किए जाते हैं जो कि वे उपयुक्त हैं। इसके अलावा, परीक्षण है। मेरे दिमाग में जोर-जबरदस्ती या पवित्रता-परीक्षण जो कि विकास के लिए एक असफल-तेज़ तदर्थ दृष्टिकोण सुनिश्चित करते थे, जो अब बहुत आसान है।

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

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

[१] एंड्रयू बिंस्टॉक द्वारा भ्रष्टाचार का ढेर

[२] पिछले लेख के जवाबों पर प्रतिक्रिया

[३] अंकल बॉब द्वारा चंचल के भ्रष्टाचार का जवाब

[४] रॉब मायर्स द्वारा एजाइल के भ्रष्टाचार का जवाब

[५] खीरे के परीक्षण से परेशान क्यों?

[६] आप इसे गलत समझ रहे हैं

[[] उपकरण से दूर कदम

[[] Num टीका के साथ रोमन अंक काता ’पर टिप्पणी

[९] रोमन अंक कमेंटरी के साथ काटा

Comments

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

— क्रेग

@ क्रेग: ठीक है! यह मेरा मतलब है कि उचित परीक्षण लिखने का तरीका नहीं जानना। एक कॉलेज के छात्र के रूप में, टैक्स कलेक्टर एक बड़ा वर्ग था जो एसओएलआईडी की उचित समझ के बिना लिखा गया था। आप बिल्कुल सही सोच रहे हैं कि यह किसी भी चीज़ की तुलना में एकीकरण परीक्षण का अधिक है, लेकिन यह हमारे लिए एक अज्ञात शब्द था। हम केवल अपने प्रोफेसर द्वारा "यूनिट" परीक्षणों के संपर्क में थे।

— IAE

Answer 2

मेरा मानना ​​है कि दोनों प्रकार के परीक्षणों का होना और जहां उपयुक्त हो, उनका उपयोग करना महत्वपूर्ण है।

जैसा आपने कहा, दो चरम सीमाएं हैं और मैं ईमानदारी से एक के साथ भी सहमत नहीं हूं।

कुंजी यह है कि इकाई परीक्षणों को व्यावसायिक नियमों और आवश्यकताओं को कवर करना है । यदि कोई आवश्यकता है कि सिस्टम को किसी व्यक्ति की उम्र को ट्रैक करना होगा, तो यह सुनिश्चित करने के लिए "तुच्छ" परीक्षण लिखें कि आयु एक नॉनवेजेटिव पूर्णांक है। आप सिस्टम द्वारा आवश्यक डेटा के डोमेन का परीक्षण कर रहे हैं: जबकि तुच्छ, इसका मूल्य है क्योंकि यह सिस्टम के मापदंडों को लागू कर रहा है ।

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

मैं दृढ़ता से इकाई परीक्षण में विश्वास करता हूं और जहां भी समझ में आता है वहां टीडीडी का उपयोग करता है। इकाई परीक्षण निश्चित रूप से बढ़ी हुई गुणवत्ता के रूप में मूल्य लाते हैं और कोड बदलते समय "तेजी से विफल" व्यवहार करते हैं। हालाँकि, पुराने 80/20 नियम को भी ध्यान में रखना है। कुछ बिंदुओं पर आप परीक्षण लिखते समय कम रिटर्न तक पहुंच जाएंगे, और आपको अधिक उत्पादक कार्य करने की आवश्यकता है, भले ही कुछ परीक्षण करने के लिए कुछ औसत दर्जे का मूल्य होना चाहिए।

Comments

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

— क्रेग

मैं किसी गणना की बात नहीं कर रहा था। यदि कोई मॉडल डेटा का एक टुकड़ा संग्रहीत करता है, तो यह डेटा को सही डोमेन के लिए मान्य कर सकता है। इस स्थिति में, डोमेन nonnegative पूर्णांकों का समूह है। गणना नियंत्रक (एमवीसी में) में होनी चाहिए, और इस उदाहरण में एक आयु गणना एक अलग परीक्षा होगी।

Answer 3

यहाँ मेरा इस पर लेना है: सभी परीक्षणों की लागत है:

• प्रारंभिक समय और प्रयास:
  • इस बारे में सोचें कि क्या परीक्षण करना है और कैसे परीक्षण करना है
  • परीक्षण को लागू करें और सुनिश्चित करें कि यह परीक्षण कर रहा है कि इसे क्या माना जाता है
• चल रही रखरखाव
  • यह सुनिश्चित करना कि परीक्षण अभी भी वही कर रहा है, जिसे कोड स्वाभाविक रूप से विकसित करता है
• परीक्षण चल रहा है
  • निष्पादन समय
  • परिणामों का विश्लेषण

हम लाभ प्रदान करने के लिए सभी परीक्षणों का भी इरादा रखते हैं (और मेरे अनुभव में, लगभग सभी परीक्षण लाभ प्रदान करते हैं):

• विनिर्देश
• कोने के मामलों को उजागर करें
• प्रतिगमन को रोकने
• स्वचालित सत्यापन
• एपीआई उपयोग के उदाहरण
• विशिष्ट गुणों की मात्रा का निर्धारण (समय, स्थान)

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

अब, आपका समय और प्रयास सीमित है। आप उन चीजों को करना पसंद करेंगे जो कम से कम लागत पर सबसे अधिक लाभ प्रदान करती हैं। और मुझे लगता है कि ऐसा करना बहुत मुश्किल काम है, कम से कम नहीं क्योंकि इसे ज्ञान की आवश्यकता हो सकती है जो किसी के पास नहीं है या प्राप्त करने के लिए महंगा होगा।

और इन विभिन्न दृष्टिकोणों के बीच असली घिसाव है। मेरा मानना ​​है कि वे सभी परीक्षण रणनीतियों की पहचान कर चुके हैं जो फायदेमंद हैं। हालांकि, प्रत्येक रणनीति में सामान्य रूप से अलग-अलग लागत और लाभ होते हैं। इसके अलावा, प्रत्येक रणनीति की लागत और लाभ संभवतः परियोजना, डोमेन और टीम की बारीकियों पर बहुत अधिक निर्भर करेगा। दूसरे शब्दों में, कई सर्वश्रेष्ठ उत्तर हो सकते हैं।

कुछ मामलों में, परीक्षणों के बिना कोड को पंप करना सबसे अच्छा लाभ / लागत प्रदान कर सकता है। अन्य मामलों में, एक संपूर्ण परीक्षण सूट बेहतर हो सकता है। अभी भी अन्य मामलों में, डिजाइन में सुधार करना सबसे अच्छी बात हो सकती है।

Answer 4

वास्तव में एक इकाई परीक्षण क्या है ? और क्या वास्तव में यहाँ खेलने में इतना बड़ा द्वंद्व है?

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

इन प्रणालियों से सभी जटिलता को खत्म करना असंभव है। लेकिन हमारा काम उस जटिलता को कम से कम और प्रबंधित करना संभव है।

क्या एक इकाई परीक्षण एक परीक्षण है जो पुष्टि करता है, उदाहरण के लिए, कि आरक्षण तीन अलग-अलग प्रणालियों में सफलतापूर्वक पोस्ट किया जाता है, एक लॉग प्रविष्टि बनाई जाती है और एक ईमेल पुष्टि बाहर भेज दी जाती है?

मैं ना कहने जा रहा हूँ । यह एक एकीकरण परीक्षण है। और उन सबसे निश्चित रूप से अपनी जगह है, लेकिन वे भी एक अलग विषय है।

एक एकीकरण परीक्षण एक संपूर्ण "सुविधा" के समग्र कार्य की पुष्टि करने के लिए काम करता है। लेकिन उस सुविधा के पीछे के कोड को सरल, परीक्षण योग्य भवन ब्लॉकों, उर्फ ​​"इकाइयों" में तोड़ दिया जाना चाहिए।

इसलिए एक यूनिट टेस्ट में बहुत सीमित गुंजाइश होनी चाहिए।

जिसका तात्पर्य यह है कि इकाई परीक्षण द्वारा परीक्षण किए गए कोड में बहुत सीमित गुंजाइश होनी चाहिए।

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

आपके साथ जो समाप्त होता है वह विश्वसनीय नींव घटकों से बना एक सिस्टम है, और आपको पता है कि क्या कोड ब्रेक के उन संस्थापक इकाइयों में से कोई भी है क्योंकि आपने सरल, छोटे, सीमित-गुंजाइश परीक्षण लिखे हैं जो आपको बताएंगे।

कई मामलों में आपको प्रति यूनिट कई परीक्षण भी करने चाहिए। परीक्षण स्वयं सरल होना चाहिए, एक परीक्षण और केवल एक व्यवहार संभव सीमा तक।

गैर-तुच्छ, विस्तृत, जटिल तर्क का परीक्षण करने वाली "यूनिट टेस्ट" की धारणा है, मुझे लगता है, एक ऑक्सिमोरोन का एक सा।

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

उन इकाइयों में से कुछ (उनमें से कई) को नकली वस्तुओं का उपयोग करके परीक्षण करने की आवश्यकता हो सकती है, लेकिन इसका मतलब यह नहीं है कि आपको अधिक जटिल या विस्तृत परीक्षण लिखना होगा।

एक आरक्षण प्रणाली की मेरी काल्पनिक उदाहरण के लिए वापस जा, तुम सच में एक जीवित आरक्षण डेटाबेस या तीसरे पक्ष सेवा (या यहां तक कि एक "देव" इसके बारे में उदाहरण) हर बार जब आप के लिए रवाना से अनुरोध भेज नहीं किया जा सकता इकाई परीक्षण अपने कोड।

तो आप मोक्स का उपयोग करते हैं जो समान इंटरफ़ेस अनुबंध प्रस्तुत करते हैं। परीक्षण तब कोड के अपेक्षाकृत छोटे, नियतात्मक चंक के व्यवहार को मान्य कर सकते हैं। हरे रंग का बोर्ड नीचे तो आपको बताता है कि आपकी नींव वाले ब्लॉक टूटे नहीं हैं।

लेकिन व्यक्तिगत इकाई परीक्षणों का तर्क यथासंभव सरल बना हुआ है।

Answer 5

यह निश्चित रूप से, सिर्फ मेरा उत्पीड़न है, लेकिन पिछले कुछ महीनों से एफएएसआरपी (सी # पृष्ठभूमि से आने वाली) में कार्यात्मक प्रोग्रामिंग सीखने में मुझे कुछ चीजों का एहसास हुआ है।

जैसा कि ओपी ने कहा है, आमतौर पर 2 प्रकार के "यूनिट टेस्ट" होते हैं जो हम दिन-प्रतिदिन देखते हैं। टेस्ट जो एक विधि के अंदर और बाहर कवर करते हैं, जो आम तौर पर सबसे अधिक मूल्यवान होते हैं, लेकिन 80% सिस्टम के लिए करना मुश्किल होता है जो "एल्गोरिदम" के बारे में कम और "अमूर्त" के बारे में अधिक होता है।

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

जब आप अपने सिस्टम को अधिक कार्यात्मक तरीके से डिजाइन करते हैं, जहां आप साइड-इफेक्ट्स पर निर्भरता के निर्माण से बचते हैं और अपरिवर्तनीयता के माध्यम से राज्य परिवर्तन / ट्रैकिंग से बचते हैं, तो यह आपको "ins और outs" परीक्षणों पर अधिक ध्यान केंद्रित करने में सक्षम बनाता है, जो स्पष्ट रूप से कार्रवाई का अधिक परीक्षण करते हैं , और कम तुम वहाँ कैसे हो। आप आश्चर्यचकित होंगे कि समान समस्याओं के लिए बहुत सी सरल समाधानों के मामले में अपरिवर्तनीयता जैसी चीजें आपको क्या दे सकती हैं, और जब आप "साइड-इफेक्ट्स" पर निर्भर नहीं हैं, तो आप लगभग बिना किसी अतिरिक्त लागत के समानांतर और अतुल्यकालिक प्रोग्रामिंग जैसी चीजें कर सकते हैं।

जब से मैंने Fsharp में कोडिंग शुरू की है, मुझे किसी भी चीज़ के लिए नकली रूपरेखा की आवश्यकता नहीं है, और यहां तक ​​कि IOC कंटेनर पर अपनी निर्भरता को पूरी तरह से बहाया है। मेरे परीक्षण व्यवसाय की आवश्यकता और मूल्य से संचालित होते हैं, न कि अत्यधिक प्रोग्रामिंग में रचना को प्राप्त करने के लिए भारी अमूर्त परतों पर।