यूनिट टेस्ट में रैंडम डेटा?


136

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

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

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

एक और सहकर्मी जोड़ा:

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

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

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


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

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

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

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

जवाबों:


72

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

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

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

मुझे नहीं पता कि आप किस भाषा का उपयोग कर रहे हैं, लेकिन यहां देखें:

जावा http://functionaljava.org/

स्काला (या जावा) http://github.com/rickynils/scalacheck

हास्केल http://www.cs.chalmers.se/~rjmh/QuickCheck/

.NET: http://blogs.msdn.com/dsyme/archive/2008/08/09/fscheck-0-2.aspx

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

खुश परीक्षण!


1
इसके लिए +1। ScalaCheck एक पुन: प्रयोज्य तरीके से न्यूनतम, यादृच्छिक परीक्षण डेटा उत्पन्न करने का एक अभूतपूर्व काम करता है।
डैनियल स्पाइवाक

17
यह यादृच्छिक नहीं है। यह मनमाना है। बड़ा अंतर :)
Apocalisp

reductiotest.org अब अस्तित्व में है, और Google ने मुझे कहीं और इंगित नहीं किया। किसी भी विचार यह अब कहाँ है?
Raedwald

अब यह कार्यात्मक जावा पुस्तकालय का हिस्सा है। लिंक संपादित किया गया। लेकिन मैं सिर्फ जावा कोड का परीक्षण करने के लिए स्कैलचेक का उपयोग करूंगा।
Apocalisp

ScalaCheck ने GitHub में स्थानांतरित कर दिया है। उत्तर में अद्यतन लिंक। यह जावा के लिए भी उपयोगी है, न कि केवल स्काला के लिए। (पुराना लिंक था code.google.com/p/scalacheck )
RobertB

38

इस तरह के परीक्षण को मंकी टेस्ट कहा जाता है । जब सही किया जाता है, तो यह वास्तव में अंधेरे कोनों से कीड़े को बाहर कर सकता है।

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


26

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

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


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

PRNG के लिए क्या है?
systemovich

छद्म रैंडम नंबर जेनरेटर
विल डीन

16

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

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


16

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

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

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

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

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

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

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


14

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

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

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

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


10

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


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

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


9

आपका सहकर्मी फ़र्ज़-परीक्षण कर रहा है , हालाँकि वह इसके बारे में नहीं जानता है। वे सर्वर सिस्टम में विशेष रूप से मूल्यवान हैं।


2
लेकिन यह इकाई परीक्षणों से एक मौलिक रूप से अलग बात नहीं है? और एक अलग समय पर किया?
एंडोलिथ

1
@endolith भौतिकी का कोई नियम नहीं है जो आपको विशेष समय पर विशेष परीक्षण चलाने के लिए मजबूर करता है
user253751

1
@ मिनीबिस लेकिन विशेष समय पर विशेष परीक्षण करने के अच्छे कारण हैं। जब भी कोई उपयोगकर्ता "ओके" बटन क्लिक करता है, तो आप हर बार यूनिट परीक्षणों की बैटरी नहीं चलाते हैं।
एंडोलिथ

5

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

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


5

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


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

1

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

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


0

आपकी ऑब्जेक्ट / ऐप के आधार पर, रैंडम डेटा का लोड टेस्टिंग में एक स्थान होगा। मुझे लगता है कि डेटा का उपयोग करना अधिक महत्वपूर्ण होगा जो स्पष्ट रूप से डेटा की सीमा स्थितियों का परीक्षण करता है।


0

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

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

क्या यह अभी भी योग्य है यादृच्छिक? बीयर पर बात करते हैं। :-)


0

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

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

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

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


-2

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

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

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


3
यादृच्छिक डेटा या यादृच्छिक बीज को लॉग करना संभव है ताकि परीक्षण को पुन: पेश किया जा सके।
cbp
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.