क्या एक इकाई परीक्षण लिखने में कोई मूल्य है जो किसी अन्य परीक्षण का सबसेट है?

15

एक छोटे से वंचित उदाहरण देने के लिए, मान लें कि मैं परीक्षण करना चाहता हूं कि एक फ़ंक्शन दो नंबर लौटाता है, और पहला वाला दूसरे से छोटा है:

def test_length():
    result = my_function()
    assert len(result) == 2

def test_order()
    a, b = my_function()
    assert a < b

यहां, अगर test_lengthअसफल हो गए, तो test_orderभी असफल हो जाएंगे। क्या इसे लिखना test_length, या इसे छोड़ना सबसे अच्छा अभ्यास है?

EDIT: ध्यान दें कि इस स्थिति में, दोनों परीक्षण ज्यादातर एक दूसरे से स्वतंत्र होते हैं, प्रत्येक को अलगाव में चलाया जा सकता है, या उन्हें रिवर्स ऑर्डर में चलाया जा सकता है, इससे कोई फर्क नहीं पड़ता। इसलिए इनमें से कोई भी पूर्व प्रश्न नहीं है

ऊपर वाले का एक डुप्लिकेट है।

unit-testing

— मिहाई
स्रोत

2

यूनिट परीक्षण के

2

@ GlenH7 - यह एक अलग प्रश्न की तरह लगता है। दूसरा "यदि आपके पास फ़ंक्शन हैं जहां Aकॉल Bऔर समान परिणाम देता है, तो क्या आपको दोनों का परीक्षण करना चाहिए Aऔर B"। यह परीक्षण के तहत फ़ंक्शन (एस) के बजाय अतिव्यापी होने के बारे में अधिक है । (हालांकि यह भ्रमित है क्योंकि वे वर्तमान में नामित हैं)।

— तेलस्तीन

एक फ़ंक्शन की कार्यक्षमता का परीक्षण कैसे किया जाना चाहिए, इसमें अन्य कार्यों का उपयोग करने वाले

— gnat

1

स्पष्ट रूप से इन परीक्षणों को बोलना वास्तव में अतिव्यापी नहीं है (उनके पास सफलता निर्भरता नहीं है)। एक फ़ंक्शन lambda: type('', (), {'__len__': lambda self: 2})()पहले पास करेगा, लेकिन दूसरा नहीं।

— लियोरी

1

@ GlenH7: FWIW, मैंने वास्तव में प्रश्न को नहीं बदला, बस इसे gnat-safe बनाने की कोशिश की; ;-) (@gnat: कोई अपराध नहीं, बस मजाक!)

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

28

मूल्य हो सकता है, लेकिन यह थोड़ा सा गंध है। या तो आपके परीक्षण अच्छी तरह से पृथक नहीं हैं (चूंकि test_orderवास्तव में दो चीजों का परीक्षण किया जाता है) या आप अपने परीक्षण में बहुत अधिक हठधर्मिता कर रहे हैं (दो परीक्षणों को एक ही तार्किक चीज़ बना रहे हैं)।

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

— Telastyn
स्रोत

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

— डॉक ब्राउन

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

— तेलस्टिन

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

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

5

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

— क्रिस हेस

@ क्रिसहैस: मैंने "कोई ज़रूरत नहीं है" लिखा था, इसमें "कोई मूल्य नहीं" है।

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

5

आपके परीक्षण स्पष्ट होने चाहिए। यह पूरी तरह से अनुमान नहीं है कि अगर text_length विफल हो जाए तो test_order विफल हो जाता है।

मुझे यकीन नहीं है कि यह पायथन में कैसे जाता है जिसे आपने पोस्ट किया है, लेकिन अगर len(result)3 है तो पहला विफल हो जाएगा लेकिन दूसरा पास हो सकता है (और यदि पायथन में नहीं है, तो जावास्क्रिप्ट जैसे भाषाओं में सुनिश्चित करें)।

जैसा आपने कहा, आप परीक्षण करना चाहते हैं कि फ़ंक्शन दो नंबर लौटाता है और वे क्रम में हैं। दो परीक्षण यह है

— मदारा का भूत
स्रोत

1

It's not completely inferred that if text_length fails test_order fails- पायथन में, यह आपको एक अपवाद देगा।

— डॉक ब्राउन

मुझे लगता है कि सवाल उस मामले के बारे में है जहां विफलता का test_lengthअर्थ है विफलता test_order। तथ्य यह है कि जावास्क्रिप्ट में लिखे गए परीक्षणों की एक समान जोड़ी समान व्यवहार नहीं करेगी क्योंकि ये दो अजगर परीक्षण अप्रासंगिक हैं।

— दाऊद का कहना है कि मोनिका

2

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

— Doc Brown

4

@DavidWallace: चूंकि हम यहाँ एक programmers.com हैं, stackoverflow.com पर नहीं, IMHO एक उत्तर देता है जिसे एक से अधिक भाषाओं में लागू किया जा सकता है, केवल एक विशेष भाषा के लिए उत्तर से बेहतर है। लेकिन जब किसी विशिष्ट भाषा का जिक्र किया जाता है, तो उत्तर भाषा के बारे में सही होना चाहिए, न कि कुछ गुणों का मिश्रण करना चाहिए।

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

1

बात यह है, "सवाल यह है कि क्या यह एक परीक्षण लिखने के लायक है जो किसी अन्य परीक्षा का सबसेट है", और यह उत्तर कहता है, "कुछ भाषाओं में, न तो आपके परीक्षणों में से कोई एक सबसेट है" और फिर दोनों परीक्षणों के निष्कर्ष पर पहुंचता है। इसलिए आवश्यक है। यह मुझे पढ़ता है जैसे कि किसी ने कहा, "आपका कोड C ++ में बिल्कुल भी संकलित नहीं होता है, और इसके अलावा, C ++ में एक फ़ंक्शन केवल एक मान लौटा सकता है, इसलिए आपको इसे दो परीक्षण करने की आवश्यकता नहीं है। केवल एक परीक्षण लिखें" ;-)

— स्टीव जेसप

2

यहां का एकमात्र मूल्य test_lengthयह है कि, अगर सब कुछ गुजरता है, तो इसकी बहुत उपस्थिति इंगित करती है कि "लंबाई" का परीक्षण किया गया है।

इसलिए इन दोनों परीक्षणों का होना वास्तव में अनावश्यक है। केवल रखें test_orderलेकिन नाम बदलने पर विचार करें test_length_and_order।

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

— दाऊद कहता है कि मोनिका को बहाल कर दो
स्रोत

1

testमस्सा पायथन के परीक्षण ढांचे के लिए सार्थक है। बेशक आप को इसके प्रशंसक होने की जरूरत नहीं है, लेकिन इसे इस्तेमाल करने वाले किसी व्यक्ति को रोकने के लिए आवश्यक तर्क का वजन बदल जाता है ;-)

— स्टीव जेसोप

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

— दाऊद का कहना है कि मोनिका को बहाल कर दिया

@ डेविडवैलस: आप चाहें तो उपसर्ग बदल सकते हैं ।

— रेयान

1

मैं इन परीक्षणों को अलग छोड़ देता हूँ अगर ऐसा है तो वे कैसे विकसित होंगे। हाँ test_orderजब भी विफल होने की संभावना test_lengthहै, लेकिन आप निश्चित रूप से जानते हैं कि क्यों।

मैं इस बात से भी सहमत हूँ कि यदि test_orderपहले दिखाई दिया और आपको एक परीक्षण योग्य विफलता मिली, तो इसका परिणाम यह था कि संभवतः दो मान नहीं थे, उस जाँच को जोड़ने assertऔर परीक्षण का नाम बदलने से test_length_and_orderसमझ में आता है।

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

लेकिन ध्यान दें कि अब आपके पास परिणाम के लिए परीक्षणों की एक बैटरी है my_function()। यदि यह परीक्षण करने के लिए कई संदर्भ (या, अधिक संभावना है, कई पैरामीटर) हैं, तो अब सभी परिणामों का परीक्षण करने के लिए एक सबरूटीन हो सकता है my_function()।

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

तो मैं शायद अपनी अलग परीक्षण के साथ शुरू और विस्तार होगा test_lengthकरने के लिए test_length_and_typesऔर छोड़ test_orderउत्तरार्द्ध यह सोचते हैं अलग, "सामान्य प्रक्रिया" के रूप में देखा जाता है।

— मार्क हर्ड
स्रोत