एक सूची का परीक्षण ... सभी एक ही परीक्षण में या प्रत्येक स्थिति के लिए एक परीक्षण?

21

मैं यह परीक्षण कर रहा हूं कि कोई फ़ंक्शन किसी सूची में क्या अपेक्षित है। इसलिए मैं परीक्षण करना चाहता हूं

f(null) -> null
f(empty) -> empty
f(list with one element) -> list with one element
f(list with 2+ elements) -> list with the same number of elements, doing what expected

ऐसा करने के लिए, सबसे अच्छा तरीका क्या है?

"WorksAsExpected" नाम के तहत सभी मामलों को एक ही (विधि) परीक्षण में परीक्षण करना,
प्रत्येक मामले के लिए एक परीक्षण रखना, इस प्रकार होना
- "WorksAsExpectedWhenNull"
- "WorksAsExpectedWhenEmpty"
- "WorksAsExpectedWhenSingleElement"
- "WorksAsExpectedWhenMoreElements"
एक और विकल्प मैं :-) के बारे में नहीं सोच रहा था

unit-testing tdd

— malarres
स्रोत

2

के संभावित डुप्लिकेट इकाई लेखन की इस पद्धति सही टेस्ट?

— gnat

2

मैं उन्हें अलग-अलग परीक्षण मामलों के रूप में लिखूंगा। यदि आपका टेस्ट सिस्टम समर्थन करता है तो आप पैरामीटराइज़ किए गए परीक्षणों का उपयोग कर सकते हैं।

— जॉन्सर्शपे

5

यदि आप अपना परीक्षण किसी दिए गए में लिखते हैं ... जब ... तब शैली तब यह स्वतः स्पष्ट हो जाता है कि उन्हें वास्तव में अलग से परीक्षण किया जाना चाहिए ...

— रॉबी डी

1

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

— फिलिप मिलोवानोविक

1

डुप्लिकेट तत्वों के साथ सूची?

— एटीनल

30

अंगूठे का सरल नियम मैं एक परीक्षण के मामले में कई परीक्षणों का एक सेट करने के लिए उपयोग करता हूं, या कई है: क्या इसमें सिर्फ एक सेटअप शामिल है?

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

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

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

— डेविड अरनो
स्रोत

14

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

आपके ढांचे के आधार पर संभव उपकरण:

सिद्धांत । एक सिद्धांत आपको डेटा के सेट के बारे में तथ्यों की एक श्रृंखला का परीक्षण करने देता है। ढांचा तब आपके परीक्षणों को कई परीक्षण डेटा परिदृश्यों के साथ खिलाएगा - या तो किसी फ़ील्ड द्वारा या डेटा को उत्पन्न करने वाली स्थैतिक विधि द्वारा। यदि आपके कुछ तथ्य कुछ पूर्व शर्त के आधार पर लागू होते हैं और अन्य ये रूपरेखाएँ किसी धारणा की अवधारणा का परिचय नहीं देते हैं । Assume.that()यदि यह पूर्व शर्त में विफल रहता है तो आपका डेटा के लिए परीक्षण को छोड़ देता है। यह आपको "वर्क्स अपेक्षा के अनुसार" परिभाषित करता है और फिर इसे बहुत सारे डेटा को फीड करता है। जब आप परिणाम देखते हैं, तो आपके पास माता-पिता के परीक्षण के लिए एक प्रविष्टि और फिर डेटा के प्रत्येक टुकड़े के लिए एक उप-प्रविष्टि होती है।
परिमार्जित परीक्षण । परिमाप्य परीक्षण सिद्धांतों के लिए एक अग्रदूत थे, इसलिए हो सकता है कि पूर्वधारणा जाँच नहीं हो रही है कि आप सिद्धांतों के साथ हो सकते हैं। अंतिम परिणाम एक जैसा है। आप परिणाम देखते हैं, आपके पास परीक्षण के लिए एक मूल प्रविष्टि है, और फिर प्रत्येक डेटा बिंदु के लिए एक विशिष्ट प्रविष्टि है।
एक परीक्षण कई जोर के साथ । सेट अप करने के लिए कम समय लगता है, लेकिन आप एक बार में समस्याओं को उजागर करते हैं। यदि परीक्षण बहुत लंबा है और कई अलग-अलग परिदृश्यों का परीक्षण किया गया है, तो दो बड़े जोखिम हैं: इसे चलाने में लंबा समय लगेगा, और आपकी टीम इससे तंग आ जाएगी और परीक्षण बंद कर देगी।
समान कार्यान्वयन के साथ कई परीक्षण । यह नोट करना महत्वपूर्ण है कि यदि दावे अलग हैं तो वे परीक्षण अतिव्यापी नहीं हैं। हालांकि, यह एक TDD केंद्रित टीम का पारंपरिक ज्ञान होगा।

मैं सख्त मानसिकता का नहीं हूं कि केवल एक ही हो सकता है assert आपके परीक्षण में बयान , लेकिन मैं प्रतिबंध लगाता हूं कि सभी मुखर एकल कार्रवाई के बाद की स्थितियों का परीक्षण करें। यदि परीक्षणों के बीच एकमात्र अंतर डेटा है, तो मैं मानकीकृत परीक्षणों या सिद्धांतों जैसे अधिक उन्नत डेटा संचालित परीक्षण सुविधाओं का उपयोग करने की मानसिकता रखता हूं।

सबसे अच्छा परिणाम क्या है यह तय करने के लिए अपने विकल्पों का वजन करें। मैं कहूंगा कि "WorksAsExpectedWhenNull" मूल रूप से उन मामलों की तुलना में अलग है जहां आप एक संग्रह के साथ काम कर रहे हैं जिसमें तत्वों की संख्या भिन्न है।

— बेरिन लोरिट्श
स्रोत

5

वे अलग-अलग परीक्षण मामले हैं, लेकिन परीक्षण के लिए कोड समान है। इसलिए मानकीकृत परीक्षणों का उपयोग करना सबसे अच्छा समाधान है। यदि आपका परीक्षण ढाँचा मानकीकरण का समर्थन नहीं करता है, तो साझा कोड को एक सहायक फ़ंक्शन में निकालें, और इसे व्यक्तिगत परीक्षण मामलों से कॉल करें।

एक परीक्षण के मामले में लूप के माध्यम से पैरामीरिजेशन से बचने की कोशिश करें, क्योंकि इससे यह निर्धारित करना मुश्किल हो जाता है कि किस डेटा सेट में त्रुटि हुई।

अपने टीडीडी रेड-ग्रीन-रिफ्लेक्टर चक्र में, आपको एक समय में एक उदाहरण डेटा सेट जोड़ना चाहिए। कई परीक्षण मामलों को एक पैरामीरिजेड परीक्षण में जोड़ना रिफैक्टरिंग कदम का हिस्सा होगा।

एक अलग दृष्टिकोण संपत्ति परीक्षण है । आप ठोस इनपुट डेटा को निर्दिष्ट किए बिना, आपके फ़ंक्शन के विभिन्न गुणों को मुखर करने वाले विभिन्न (पैराड्राइज्ड) परीक्षण बनाएंगे। जैसे कोई प्रॉपर्टी हो सकती है: सभी सूचियों के लिए xs, सूची ys = f(xs)की लंबाई समान है xs। परीक्षण ढांचा तब दिलचस्प सूचियाँ और यादृच्छिक सूचियाँ उत्पन्न करेगा, और यह दावा करेगा कि आपके गुण उन सभी के लिए हैं। यह मैन्युअल रूप से निर्दिष्ट उदाहरणों से दूर जाता है, क्योंकि मैन्युअल रूप से उदाहरण चुनने से दिलचस्प किनारे के मामलों को याद किया जा सकता है।

— आमोन
स्रोत

क्या अंतिम वाक्य में "मिस" नहीं "ढूंढना" चाहिए?

— रॉबी डी

@ रॉबीडी इंग्लिश अस्पष्ट, फिक्स्ड है।

— आमोन

3

प्रत्येक मामले के लिए एक परीक्षण करना उचित है क्योंकि प्रत्येक परीक्षण में एक एकल अवधारणा का परीक्षण करना एक अच्छा दिशानिर्देश है जिसकी अक्सर सिफारिश की जाती है।

इस पोस्ट को देखें: क्या एकल इकाई परीक्षण में कई दावे करना ठीक है? । वहाँ एक प्रासंगिक और विस्तृत चर्चा है:

मेरी दिशानिर्देश आमतौर पर है कि आप प्रति परीक्षण एक तार्किक अवधारणा का परीक्षण करते हैं। आप एक ही वस्तु पर कई जोर दे सकते हैं। वे आमतौर पर एक ही अवधारणा का परीक्षण किया जाएगा। स्रोत - रॉय ओशेरोव

[...]

टेस्ट केवल एक कारण के लिए असफल होना चाहिए, लेकिन इसका मतलब यह नहीं है कि केवल एक मुखर कथन होना चाहिए। IMHO "अरेंज, एक्ट, एस्टर" पैटर्न को पकड़ना अधिक महत्वपूर्ण है।

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

— लल्लू
स्रोत

0

मेरे विचार में, यह परीक्षण की स्थिति पर निर्भर करता है।

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

— HungDL
स्रोत

यह एक टिप्पणी की तरह अधिक पढ़ता है, देखें कैसे जवाब दें

— gnat