मैंने अपनी कक्षा का परीक्षण कर लिया है, अब मैं एकीकरण परीक्षण के साथ कैसे आरंभ कर सकता हूं?


19

मैंने एक वर्ग लिखा है जो MailChimpRecipient नामक MailChimp सूची में प्राप्तकर्ताओं का प्रबंधन करता है। यह MCAPI वर्ग का उपयोग करता है, जो एक तृतीय-पक्ष एपीआई आवरण है।

http://apidocs.mailchimp.com/api/1.3/ http://apidocs.mailchimp.com/api/downloads/

मैं MailChimpRecipient ऑब्जेक्ट के कंस्ट्रक्टर में MCAPI ऑब्जेक्ट को पास करता हूं, इसलिए मैंने PHPUnit का उपयोग करके यूनिट टेस्ट लिखा है जो मेरी अपनी कक्षा में सभी लॉजिक का परीक्षण करता है (मैं MCAPI क्लास का परीक्षण नहीं कर रहा हूं)। मेरे पास 100% कोड कवरेज है और सभी परीक्षण पास हैं। यह MCAPI ऑब्जेक्ट को मॉकिंग और स्टबिंग करके किया जाता है।

मेरा अगला चरण एक एकीकरण परीक्षण लिखना था, PHPUnit का उपयोग करके भी, जहां मैं एक वास्तविक MCAPI सूची का उपयोग करने के लिए सेट की गई वास्तविक MCAPI ऑब्जेक्ट का उपयोग करके MailChimpRecipient स्थिरता का निर्माण करूंगा।

मैंने लिखा है कि मुझे लगता है कि एक इंटरग्रेशन टेस्ट है, जो मूल रूप से परीक्षण फिर से ऑब्जेक्ट के सार्वजनिक इंटरफ़ेस को चलाता है, जैसे:

public function testAddedRecipientCanBeFound()
{
    $emailAddress = 'fred@fredsdomain.com';
    $forename = 'Fred';
    $surname = 'Smith';

    // First, delete the email address if it is already on the list
    $oldRecipient = $this->createRecipient();
    if($oldRecipient->find($emailAddress))
    {
        $oldRecipient->delete();
    }
    unset($oldRecipient);

    // Add the recipient using the test data
    $newRecipient = $this->createRecipient();
    $newRecipient->setForename($forename);
    $newRecipient->setSurname($surname);
    $newRecipient->setEmailAddress($emailAddress);
    $newRecipient->add();
    unset($newRecipient);

    // Assert that the recipient can be found using the same email address
    $this->assertTrue($this->_recipient->find($emailAddress));
}

"एकीकरण" परीक्षण कक्षा के किसी भी आंतरिक परीक्षण नहीं करता है - यह सिर्फ यह सुनिश्चित करता है कि एक वास्तविक MCAPI वस्तु दी गई है, यह विज्ञापित के रूप में व्यवहार करता है।

क्या ये सही है? क्या यह एक अंतर परीक्षण परीक्षण चलाने का सबसे अच्छा तरीका है? आखिरकार, इंटर्नल को एक इकाई परीक्षण के साथ परीक्षण किया गया है। क्या मैं यह सोचने में सही हूं कि एकीकरण परीक्षण यह परीक्षण करने के लिए है कि यह वास्तव में काम करता है, जिस तरह से इसका व्यवहार विज्ञापित है?

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

क्या यह आवाज़ उचित है? इकाई परीक्षण किसी वस्तु के आंतरिक परीक्षणों का परीक्षण करते हैं, अंतर परीक्षण परीक्षण सुनिश्चित करते हैं कि यह विज्ञापित के रूप में व्यवहार करता है?


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

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

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

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

1
+1 अच्छे प्रश्न के लिए, लेकिन प्रोग्रामर को माइग्रेट करने के लिए भी मतदान किया। ऐसा लगता है कि जहां परीक्षण रणनीतियों पर सवाल हैं
गॉर्डन मे

जवाबों:


17

अपने कोड का परीक्षण करते समय आपको तीन क्षेत्रों पर ध्यान देना चाहिए:

  • परिदृश्य परीक्षण
  • क्रियात्मक परीक्षण
  • इकाई का परीक्षण

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

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

इकाई परीक्षण के साथ आप सभी संभावनाओं का परीक्षण करते हैं, इसलिए न केवल 'खुश मार्ग' बल्कि सभी त्रुटि स्थितियां भी।

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

उदाहरण के लिए, मान लीजिए कि आप कार का परीक्षण कर रहे हैं।

आप पूरी कार को इकट्ठा कर सकते हैं और एक ड्राइवर के रूप में हर संभव स्थिति की जांच कर सकते हैं लेकिन ऐसा करना वास्तव में कठिन होगा।

इसके बजाय आप सभी संभावनाओं के साथ इंजन के एक छोटे हिस्से का परीक्षण करेंगे (यूनिट टेस्ट)

फिर आप पूरे इंजन (कार से अलग) का परीक्षण करते हैं जो एक कार्यात्मक परीक्षण होगा।

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

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

कुछ अन्य बिंदु,

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

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

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

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

धन्यवाद दोस्तों! जब यह अच्छा परीक्षण योग्य कोड लिखने की बात आती है, तो बहुत कुछ सीखने को नहीं मिलता है। मैंने खुद को इस पुस्तक की एक प्रति देने का आदेश दिया है: amazon.co.uk/… । उम्मीद है, आपने जो कुछ कहा है, वह मेरे पढ़ने के बाद थोड़ा अधिक समझ में आएगा। @ राउटर, मैं सिर्फ प्राप्तकर्ता को हटा रहा हूं क्योंकि परीक्षण से सूची में एक ईमेल पता जुड़ जाएगा। मैं इसे हटा रहा हूं ताकि सूची उस परीक्षण से अप्रभावित रहे।

1
@LewisBassett मैं कोई Php डेवलपर नहीं हूं, लेकिन xUnit टेस्ट पैटर्न ( amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054 ) निश्चित रूप से एक अच्छा पढ़ा है। इसके अलावा misko.hevery.com/code-reviewers-guide पर लेख वास्तव में दिलचस्प हैं।
राउटर डी कोर्ट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.