क्या हर कदम के लिए अलग-अलग परीक्षण विधियाँ होना एक अच्छा विचार है?

Question

मैं एक अन्य परीक्षण कर रहा हूं। मान लीजिए कि यह JSON संरचना देता है। सर्वर का परीक्षण करने के लिए सबसे अच्छा तरीका क्या है? प्रत्येक परीक्षण कदम केवल तभी सफल हो सकता है जब सभी पिछले सफल रहे हों।

संरचना ए: एक बार में सब कुछ का परीक्षण करें

- Test method 1:
    - make server request
    - assert http response code was 200
    - assert returned file is not empty
    - assert returned file has valid JSON syntax
    - assert returned JSON contains key X

यह सबसे अच्छा समाधान प्रतीत होता है।

लाभ:

• केवल एक सर्वर अनुरोध
• मैं एक पूरे के रूप में व्यवहार का परीक्षण कर रहा हूं "क्या सर्वर कुंजी X के साथ JSON लौटाता है?"

संरचना बी: धीरे-धीरे प्रत्येक परीक्षण में जोर डालें

 - Test method 1:
     - make server request
     - assert http response code was 200
 - Test method 2:
     - make server request
     - assert returned file is not empty
 - Test method 3:
     - make server request
     - assert returned file has valid JSON syntax
 - Test method 4:
     - make server request
     - assert returned JSON contains key X

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

संरचना सी: एक बार अनुरोध करें और कैश्ड प्रतिक्रिया पर अलग-अलग परीक्षण विधियां चलाएं

- make server request and cache it (allow read-only access)

 - Test method 1:
     - assert http response code was 200 on cached server request
 - Test method 2:
     - assert returned file is not empty on cached server request
 - Test method 3:
     - assert returned file has valid JSON syntax on cached server request
 - Test method 4:
     - assert returned JSON contains key X on cached server request

लाभ:

• कोई दोहराया (महंगा) सर्वर अनुरोध
• अभी भी एकल-परख परीक्षण के तरीके हैं

उपयोग करने के लिए सबसे समझदार परीक्षण संरचना कौन सी है?

Comments

कृपया अपने प्रश्न को बाद में ऐसे तरीके से बदलना बंद करें जो मौजूदा उत्तरों को अमान्य करता है! धन्यवाद।

— डॉक्टर ब्राउन

आपको असुविधा के लिए खेद है लेकिन क्या आप अन्यथा करने का प्रस्ताव करेंगे?

— mrplow

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

— डॉक्टर ब्राउन

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

— mrplow

Answer 1

सर्वोत्तम प्रथाओं का हमेशा एक उद्देश्य होता है, उनके पीछे एक कारण। अपने डिजाइन में इन कारणों पर विचार करना हमेशा एक अच्छा विचार है - खासकर जब आप यह तय करने की कोशिश कर रहे हैं कि इन सर्वोत्तम प्रथाओं का पालन कैसे और कितना कठिन है।

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

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

तो, आपको अपने आप से पूछने की ज़रूरत है - "क्या मुझे वास्तव में इस गारंटी की आवश्यकता है?"

मान लीजिए कि पहले परीक्षण मामले में एक बग है - HTTP प्रतिक्रिया कोड नहीं है 200। इसलिए आप कोड को हैक करना शुरू करते हैं, यह पता करें कि आपके पास जो प्रतिक्रिया कोड होना चाहिए वह क्यों नहीं मिला, और समस्या को ठीक करें। और अब क्या है?

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

विचार करने के लिए कुछ और चीजें हैं:

आश्रितों की निर्भरता

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

यदि आपके पास REST सेवा (या कोई अन्य HTTP प्रोटोकॉल) है जो JSON प्रारूप में प्रतिक्रियाएं देता है, तो आप आमतौर पर एक साधारण ग्राहक वर्ग लिखते हैं जो आपको नियमित तरीकों की तरह नियमित तरीकों की तरह REST विधियों का उपयोग करने देता है। यह मानते हुए कि क्लाइंट के पास यह सुनिश्चित करने के लिए अलग-अलग परीक्षण हैं कि मैं काम कर रहा हूं, पहले 3 ऐसर्ट्स को डिसाइड किया और केवल 4 को ही रखा!

क्यों?

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

इसलिए आपको इन सभी परीक्षणों को चलाने की आवश्यकता नहीं है - बस चौथा परीक्षण चलाएं, और यदि कोई भी पहला परीक्षण करने की कोशिश करता है, तो यह पता लगाने की कोशिश करता है कि पहले तीन में से कोई भी बग विफल हो जाएगा।

आप रिपोर्ट कैसे प्राप्त करना चाहते हैं?

मान लीजिए कि आपको परीक्षण सर्वर से ईमेल नहीं मिलते हैं, लेकिन इसके बजाय क्यूए विभाग परीक्षण चलाता है और आपको असफल परीक्षणों के बारे में सूचित करता है।

क्यूए से जैक आपके दरवाजे पर दस्तक देता है। उनका कहना है कि पहला परीक्षण तरीका विफल रहा, और REST पद्धति ने खराब प्रतिक्रिया कोड दिया। आप उसे धन्यवाद देते हैं, और मूल कारण की तलाश शुरू करते हैं।

उसके बाद QA से जेन आता है, और कहता है कि तीसरा परीक्षण तरीका विफल हो गया - REST पद्धति ने प्रतिक्रिया निकाय में एक वैध JSON नहीं लौटाया। आप उसे बताएं कि आप पहले से ही उस पद्धति को देख रहे हैं, और आप एक ही बात मानते हैं कि यह एक बुरा निकास कोड वापस करने का कारण बना, यह भी ऐसा कारण है जो एक वैध JSON नहीं है, और अपवाद स्टैक ट्रेस की तरह दिखता है।

आप काम पर वापस लौट जाते हैं, लेकिन फिर क्यूए से जिम आता है, यह कहते हुए कि चौथी परीक्षा विधि विफल हो गई और प्रतिक्रिया में कोई एक्स कुंजी नहीं है ...

आप इस कारण को भी नहीं देख सकते क्योंकि जब आपके पास कंप्यूटर स्क्रीन नहीं है तो कोड को देखना कठिन है। अगर जिम जल्दी होता तो वह समय पर चकमा दे सकता था ...

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

Answer 2

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

और यदि आप इसे सुरक्षित रूप से ग्रहण नहीं कर सकते हैं और इसे परीक्षण का हिस्सा बनाना चाहते हैं, तो आप कई बार परीक्षा A को चलाने के लिए बेहतर हो सकते हैं।

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

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

TLDR: A से शुरू करें यदि आप सुनिश्चित हैं कि आप हमेशा चाहते हैं कि सभी परीक्षण एक परीक्षण में चलाए जाएं, तो C को रिफ्लेक्टर करें यदि आपको लगता है कि आपको अलग-अलग आश्रयों के बारे में बाहर से आसान नियंत्रण की आवश्यकता है।

Answer 3

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

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

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

Answer 4

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

---

कोई भी कोड लिखते समय (या शायद कुछ और भी बना रहे हैं), हमेशा अपने आप से पूछें: "ऐसा अभ्यास क्यों है?"
हम क्यों कहते हैं कि हर चीज के लिए अलग-अलग परीक्षण होने चाहिए?

जब आपको इसकी आवश्यकता हो तो दो मामले हैं:

1. जब आप "प्रत्येक परीक्षण कदम केवल तभी सफल हो सकता है जब सभी पिछले सफल थे" पर भरोसा नहीं कर सकते
2. जब आपके परीक्षणों में वर्णनात्मक मुखर संदेश नहीं होते हैं

इन मामलों का सामना करने के दो कारण हैं:

1. "प्रत्येक परीक्षण कदम केवल तभी सफल हो सकता है जब सभी पिछले सफल थे" वास्तव में आपके उत्पाद की सुविधा के लिए लागू नहीं है
2. आपको अनुभव या समय की कमी, या उत्पाद की जटिलता के कारण उत्पाद का पर्याप्त ज्ञान नहीं है

यदि आप किसी कारण से कम से कम इन कारणों में से कम से कम एक को घोषित नहीं कर सकते हैं तो बस आँख बंद करके बी संरचना ले लें ।

---

अन्यथा (मुझे उम्मीद है कि आप यहां पहुंचेंगे) आप ए चुनते हैं ।

---

इसके अलावा आप सॉफ्टवेयर क्वालिटी एश्योरेंस एंड टेस्टिंग स्टेक्सचेंज साइट पर यह सवाल पूछ सकते हैं ।