unit testing - यूनिट टेस्ट में यादृच्छिक डेटा?




unit-testing tdd (11)

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

मैंने उन्हें इसके खिलाफ कई अलग-अलग कारण दिए हैं, मुख्य हैं:

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

एक और सहकर्मी ने कहा:

  • यदि मैं अपवाद का परीक्षण कर रहा हूं, तो यादृच्छिक मान यह सुनिश्चित नहीं करेंगे कि परीक्षण अपेक्षित स्थिति में समाप्त हो जाए
  • यादृच्छिक डेटा का उपयोग सिस्टम को लोड करने और परीक्षण परीक्षण के लिए किया जाता है, यूनिट परीक्षणों के लिए नहीं

क्या कोई और अतिरिक्त कारण जोड़ सकता है जिसे मैं उसे ऐसा करने से रोकने के लिए दे सकता हूं?

(या वैकल्पिक रूप से, यह यूनिट परीक्षण लिखने का एक स्वीकार्य तरीका है, और मैं और मेरा अन्य सहकर्मी गलत है?)


  • यदि यह एक यादृच्छिक मूल्य है और परीक्षण विफल रहता है, तो हमें ऑब्जेक्ट को ठीक करने की आवश्यकता है और बी) हर बार उस मूल्य के परीक्षण के लिए खुद को मजबूर करें, इसलिए हम जानते हैं कि यह काम करता है, लेकिन चूंकि यह यादृच्छिक है, हम नहीं जानते कि मूल्य क्या था

यदि आपका टेस्ट केस सटीक रूप से रिकॉर्ड नहीं करता है कि यह परीक्षण कर रहा है, तो शायद आपको टेस्ट केस रिकोड करना होगा। मैं हमेशा लॉग रखना चाहता हूं कि मैं परीक्षण मामलों के लिए वापस देख सकता हूं ताकि मुझे पता चले कि यह स्थिर या यादृच्छिक डेटा का उपयोग करने में विफल होने के कारण क्या हुआ।


आपका सहकर्मी fuzz-testing कर रहा है, हालांकि उसे इसके बारे में पता नहीं है। वे सर्वर सिस्टम में विशेष रूप से मूल्यवान हैं।


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


इस प्रकार के परीक्षण को बंदर परीक्षण कहा जाता है। सही होने पर, यह वास्तव में अंधेरे कोनों से बग को धुआं सकता है।

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


क्या आप एक बार कुछ यादृच्छिक डेटा उत्पन्न कर सकते हैं (मेरा मतलब है कि वास्तव में एक बार परीक्षण प्रति बार नहीं), फिर उसके बाद सभी परीक्षणों में इसका उपयोग करें?

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


जब आपका यह देखने में असफल रहा कि क्या उसने इसे ठीक किया है तो आपका लड़का फिर से परीक्षा कैसे चला सकता है? मैं परीक्षणों की दोहराने योग्यता खो देता है।

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

तो मैं उनके साथ तर्क का प्रयोग करता हूं कि वह आलसी है। या, इसे एक और तरीका रखने के लिए, अगर वह यह समझने में समय नहीं लगाता कि वह इसका परीक्षण करने की कोशिश कर रहा है तो शायद वह दिखाता है कि वह वास्तव में वह कोड नहीं समझ रहा है जो वह लिख रहा है।


मैं परीक्षण डेटा समस्या के तीन समाधानों पर विचार कर सकता हूं:

  • निश्चित डेटा के साथ परीक्षण करें
  • यादृच्छिक डेटा के साथ परीक्षण करें
  • यादृच्छिक डेटा एक बार उत्पन्न करें, फिर इसे अपने निश्चित डेटा के रूप में उपयोग करें

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

यादृच्छिक परीक्षणों को कभी भी आपके दोहराने योग्य परीक्षणों को याद करने की उम्मीद नहीं की जानी चाहिए। आपको दोहराने योग्य परीक्षणों के साथ सब कुछ शामिल करना चाहिए, और यादृच्छिक परीक्षणों को बोनस पर विचार करना चाहिए। अगर उन्हें कुछ मिलता है, तो ऐसा कुछ होना चाहिए जिसे आप उचित रूप से भविष्यवाणी नहीं कर सकते; एक असली oddball।


मैं यादृच्छिक परीक्षण के पक्ष में हूं, और मैं उन्हें लिखता हूं। हालांकि, चाहे वे किसी विशेष निर्माण वातावरण में उपयुक्त हों और जिन परीक्षणों में उन्हें शामिल किया जाना चाहिए, वे एक अधिक ज्ञात प्रश्न हैं।

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

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

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

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

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

यादृच्छिक परीक्षणों, विशेष रूप से अच्छी तरह से लिखे गए लोगों के लिए बहुत कुछ कहना है, इसलिए उन्हें खारिज करने के लिए बहुत जल्दी मत बनो!


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

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

मैं अतिरंजित हूं हालांकि मैं अपने परीक्षण में यादृच्छिक डेटा को एक संकेत के रूप में इंजेक्ट करना पसंद करता हूं कि "इस चर के मूल्य को इस परीक्षण के नतीजे को प्रभावित नहीं करना चाहिए"।

मैं कहूंगा कि यदि आप एक यादृच्छिक चर का उपयोग करते हैं तो उस चर के आधार पर अपना परीक्षण फोर्क करें, फिर यह एक गंध है।


यहां एक आधे रास्ते का घर है जिसमें कुछ उपयोग है, जो आपके पीआरएनजी को लगातार स्थिर करता है। इससे आपको 'यादृच्छिक' डेटा उत्पन्न करने की अनुमति मिलती है जो दोहराने योग्य है।

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


सुंदर संहिता पुस्तक में, "सुंदर टेस्ट" नामक एक अध्याय है, जहां वह बाइनरी खोज एल्गोरिदम के लिए एक परीक्षण रणनीति के माध्यम से जाता है। एक पैराग्राफ को "परीक्षण के यादृच्छिक अधिनियम" कहा जाता है, जिसमें वह एल्गोरिदम का पूरी तरह से परीक्षण करने के लिए यादृच्छिक सरणी बनाता है। आप Google पुस्तकें, पेज 95 पर इनमें से कुछ ऑनलाइन पढ़ सकते हैं, लेकिन यह एक अच्छी किताब है।

तो मूल रूप से यह दिखाता है कि परीक्षण के लिए यादृच्छिक डेटा उत्पन्न करना एक व्यवहार्य विकल्प है।





mocking