पर्ल परीक्षणों को लिखते समय सबसे अच्छा अभ्यास क्या है जिसमें यादृच्छिकता शामिल है?

Question

मेरे मॉड्यूल List::Gen पर कुछ अपडेट्स पर काम करते समय, मैंने ->pick(num) विधि जोड़ने का निर्णय लिया, जो num अपने स्रोत से यादृच्छिक तत्वों की आकार की सूची लौटाएगा। इस परीक्षण के लिए, मैं srand इस्तेमाल किया यादृच्छिक संख्या जनरेटर बीज के, और प्रपत्र के कई परीक्षण किए गए:

srand 1234; 
is $src->pick(5)->str, '3 6 1 7 9'; 

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

तो सवाल यह है कि इन कार्यों का परीक्षण करने के लिए सबसे अच्छा क्रॉस प्लेटफ़ॉर्म तरीका क्या है? क्या मुझे अपने स्वयं के साथ rand फ़ंक्शन को अधिभारित करना चाहिए? क्या मुझे उन कार्यों के लिए हुक में निर्माण करना चाहिए जो rand का उपयोग "परीक्षण" मोड को सक्षम करने के लिए करते हैं जो अनुमानित आउटपुट उत्पन्न करता है? क्या अन्य विधियां हैं?

मैं उत्तर पसंद करूंगा जिसमें मूल पर्ल तकनीक शामिल है, क्योंकि मैं मॉड्यूल के निर्भरता पेड़ को छोटा रखने की कोशिश कर रहा हूं।

Test::Random और Test::MockRandom सीपीएएन के सुझाव प्रतीत होते हैं, क्या किसी को इन मॉड्यूल के साथ अनुभव है?

Answer 1

मैंने या तो एक का उपयोग नहीं किया है।

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

टेस्ट :: मॉकरैंडम मॉड्यूल रैंड() फ़ंक्शन को एक निर्धारिक अनुक्रम लौटने के लिए मजबूर करता है।

Answer 2

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

Answer 3

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

यादृच्छिक संख्या डोमेन के लिए आवेदन किया है, हम की तरह कुछ है:

use strict; 
use warnings; 

package Foo; 

sub new { 
    my ($class) = @_; 

    return bless {} => $class; 
} 

sub get_random_number { 
    return rand(); 
} 

package main; 
use Test::MockObject::Extends; 
use Test::More tests => 1; 

my $foo = Test::MockObject::Extends->new(Foo->new()); 
$foo->set_series(get_random_number => 0.5, 0.001, 0.999); 

is($foo->get_random_number, 0.5); 

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

अपने विशिष्ट समस्या के मामले में, आप pick से बाहर rand पर निर्भरता कारक है, तो List::Gen का एक परीक्षण योग्य संस्करण में निकाली गई विधि को ओवरराइड की जरूरत है। Test::MockObject::Extends इस आवश्यकता के लिए काफी उपयुक्त है।

Answer 4

शायद यादृच्छिक हिस्सा आपके परीक्षणों के लिए कोई फर्क नहीं पड़ता?निम्नलिखित के लिए जांच कर सकता है

गुजर परीक्षण:

1. किया -> पिकअप (एक्स) वापसी एक्स तत्वों?
2. क्या सभी एक्स तत्व $ src सूची का हिस्सा हैं?
3. 0, 1, के लिए टेस्ट आदि ...
4. (शायद?) टेस्ट कि दो अलग अलग srand बीज अलग-अलग सूचियां

यह अनिवार्य रूप से है क्या आप पहले से ही, क्या कर रहे हैं जब से तुम लेने के लिए कोशिश कर रहे हैं वापसी समीकरण के बाहर रैंड()। साथ ही साथ सभी तरह से जा सकते हैं और परीक्षण कर सकते हैं कि आपका कार्य टिन पर जो कहता है वह करता है।