क्या एकीकरण परीक्षण सभी इकाई परीक्षणों को दोहराने के लिए हैं?

Question

मान लें कि मेरे पास एक फ़ंक्शन है (रूबी में लिखा गया है, लेकिन सभी को समझना चाहिए):

def am_I_old_enough?(name = 'filip')
   person = Person::API.new(name)
   if person.male?
      return person.age > 21
   else
      return person.age > 18
   end
end

इकाई परीक्षण में मैं सभी परिदृश्यों को कवर करने के लिए चार परीक्षण बनाऊंगा। प्रत्येक Person::APIठूंसी हुई विधियों के साथ नकली वस्तु का उपयोग करेगा male?और age।

अब बात आती है एकीकरण परीक्षण लिखने की। मुझे लगता है कि व्यक्ति :: एपीआई को किसी भी तरह से मजाक नहीं किया जाना चाहिए। तो मैं वास्तव में एक ही चार परीक्षण मामलों का निर्माण करेगा, लेकिन व्यक्ति :: एपीआई वस्तु का मजाक उड़ाए बिना। क्या वो सही है?

यदि हाँ, तो इकाई परीक्षणों को लिखने का क्या मतलब है, अगर मैं सिर्फ एकीकरण परीक्षण लिख सकता हूं जो मुझे अधिक विश्वास देता है (जैसा कि मैं वास्तविक वस्तुओं पर काम करता हूं, न कि स्टब्स या नकली)?

Comments

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

— क्रिस वोहलर्ट

केवल चार परीक्षण? आपकी छह सीमाएं हैं जिनका आपको परीक्षण करना चाहिए: 17, 18, 19, 20, 21, 22 ...;)

— डेविड अरनो

@FilipBartuzi, मुझे लगता है कि विधि जाँच कर रही है कि क्या एक पुरुष उदाहरण के लिए 21 वर्ष से अधिक है? जैसा कि वर्तमान में लिखा गया है, यह ऐसा नहीं करता है, यह केवल सच है अगर वे 22+ हैं। अंग्रेजी में "21 से अधिक" का अर्थ "21+" है। तो आपके कोड में एक बग है। इस तरह के कीड़े पर सीमा मानों का परीक्षण करके कब्जा कर लिया जाता है, अर्थात् 20, 21, 22 एक पुरुष के लिए, 17,18,19 इस मामले में एक महिला के लिए। इसलिए कम से कम छह परीक्षणों की जरूरत है।

— डेविड अरनो

0 और -1 के मामलों का उल्लेख नहीं। -1 साल के व्यक्ति के लिए इसका क्या मतलब है? यदि आपका एपीआई कुछ निरर्थक देता है तो आपके कोड को क्या करना चाहिए?

— रबरडुक

यदि आप किसी व्यक्ति ऑब्जेक्ट को पैरामीटर के रूप में पास करते हैं तो यह परीक्षण करना बहुत आसान होगा।

— जेएफओ

Answer 1

नहीं, एकीकरण परीक्षण सिर्फ यूनिट परीक्षणों के कवरेज की नकल नहीं करना चाहिए । वे कुछ कवरेज की नकल कर सकते हैं , लेकिन यह बात नहीं है।

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

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

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

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

Comments

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

— jpmc26

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

— बार्ट वैन नीरोप

The customer doesn't care about a particular utility function you wrote, they care that their web app is properly secured against access by minors-> यह बहुत चालाक मानसिकता है, धन्यवाद! समस्या तब है जब आप अपने लिए प्रोजेक्ट करते हैं। एक प्रोग्रामर होने और एक ही समय में एक उत्पाद प्रबंधक होने के बीच अपनी मानसिकता को विभाजित करना मुश्किल है

— फिलिप बार्टुज़ी

Answer 2

संक्षिप्त जवाब नहीं है"। अधिक दिलचस्प बात यह है कि यह स्थिति क्यों / कैसे उत्पन्न हो सकती है।

मुझे लगता है कि भ्रम पैदा हो रहा है क्योंकि आप कोड के लिए सख्त परीक्षण प्रथाओं (इकाई परीक्षण बनाम एकीकरण परीक्षण, मॉकिंग, आदि) का पालन करने की कोशिश कर रहे हैं जो सख्त प्रथाओं का पालन नहीं करता है।

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

सबसे स्पष्ट कारण यह है कि आपका कार्य दो भिन्न कार्य कर रहा है:

• Personउनके नाम के आधार पर देख रहे हैं । इसके लिए एकीकरण परीक्षण की आवश्यकता है, यह सुनिश्चित करने के लिए कि यह उन Personवस्तुओं को पा सकता है जो संभवतः अन्यत्र निर्मित / संग्रहीत हैं।
• Personउनकी लिंग के आधार पर गणना करना कि क्या यह काफी पुराना है। यह सुनिश्चित करने के लिए यूनिट परीक्षण की आवश्यकता है, गणना अपेक्षित रूप से करती है।

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

यदि हम एक विकल्प की कल्पना करते हैं, तो हमारे पास स्वयं इसकी गणना हो सकती है:

def is_old_enough?(person)
   if person.male?
      return person.age > 21
   else 
      return person.age > 18
   end
end

चूंकि यह एक शुद्ध गणना है, इसलिए हमें इस पर एकीकरण परीक्षण करने की आवश्यकता नहीं है।

हमें लुकअप कार्य को अलग से लिखने के लिए भी लुभाया जा सकता है:

def person_from_name(name = 'filip')
   return Person::API.new(name)
end

हालाँकि, इस मामले में कार्यक्षमता इतनी करीब है Person::API.newकि मैं कहूंगा कि आपको इसका उपयोग करना चाहिए (यदि डिफ़ॉल्ट नाम आवश्यक है, तो क्या यह क्लास विशेषता की तरह कहीं और संग्रहीत किया जाएगा?)।

जब आप Person::API.new(या person_from_name) के लिए एकीकरण परीक्षण लिख रहे हैं, तो आपको इस बात की परवाह करने की ज़रूरत है कि क्या आपको उम्मीद वापस मिल रही है Person; सभी आयु-आधारित गणनाओं का कहीं और ध्यान रखा जाता है, इसलिए आपके एकीकरण परीक्षण उन्हें अनदेखा कर सकते हैं।

Answer 3

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

इसके अलावा, यूनिट टेस्ट आमतौर पर बिल्ड टाइम (बिल्ड मशीन पर) और इंटीग्रेशन टेस्ट पर्यावरण / मशीन पर तैनाती के बाद चलते हैं।

आमतौर पर हर बिल्ड के लिए कई तरह के यूनिट टेस्ट होते हैं, और फिर हर तैनाती के बाद हमारे 100 या इतने उच्च मूल्य एकीकरण परीक्षण। हम प्रत्येक बिल्ड को परिनियोजन के लिए नहीं ले जा सकते हैं, लेकिन यह ठीक है क्योंकि हम जिस परिनियोजन को ले जा रहे हैं वह एकीकरण परीक्षण चलाएगा। आमतौर पर, हम इन परीक्षणों को 10 या 15 मिनट के भीतर चलाने के लिए सीमित करना चाहते हैं क्योंकि हम तैनाती को लंबे समय तक रोकना नहीं चाहते हैं।

इसके अतिरिक्त, एक साप्ताहिक कार्यक्रम में हम एकीकरण परीक्षणों का एक प्रतिगमन सूट चला सकते हैं जो सप्ताहांत या अन्य डाउन समय में अधिक परिदृश्यों को कवर करते हैं। इसमें 15 मिनट से अधिक समय लग सकता है क्योंकि अधिक परिदृश्य कवर किए जाएंगे, लेकिन आम तौर पर कोई भी सत / सन पर काम नहीं कर रहा है, इसलिए हम परीक्षणों के साथ अधिक समय ले सकते हैं।

Comments

डायनामिक भाषाओं पर लागू नहीं होता (अर्थात बिना बिल्ड स्टेज के)

— फिलिप बार्टूज़ी