क्या एकल-अभिकल्पक इकाई परीक्षण DRY सिद्धांत को नहीं तोड़ता है?

Question

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

तो क्या एकल-परीक्षण परीक्षण DRY का उल्लंघन करता है?

और क्या एक अच्छा संतुलन का पालन करने के लिए एक अच्छा नियम है , जैसे कि प्रति विधि केवल एक परीक्षा ? *

* मुझे एहसास है कि शायद इसका एक हल नहीं है, लेकिन इसका समाधान करने के लिए एक अनुशंसित तरीका है?

Comments

आप जिस कोड को विधियों में कॉपी करते हैं, उसे निकाल सकते हैं

— इस्माइल बदावी

@IsmailBadawi जो एक अच्छे विचार की तरह लगता है। मुझे लगता है कि इन विधियों को उस क्लास ऑब्जेक्ट का एक उदाहरण लौटना चाहिए जिसका मैं परीक्षण कर रहा हूं

— कोरी हिंटन

आप परीक्षण के लिए दिए गए राज्य में कुछ बना रहे हैं? यह एक स्थिरता की तरह लगता है।

— डेव हिलियर

@DaveHillier हाँ, मैंने आज एक नया शब्द सीखा। धन्यवाद :)

— कोरी हिंटन

इस बात पर निर्भर करता है कि आप प्रति परीक्षण 1 मुखर व्याख्या कैसे करते हैं, यदि आपका मतलब है कि एक जोर * बुलाओ तो हाँ, यदि आप यह भी सुनिश्चित करना चाहते हैं कि हमलावर अभी भी पकड़ (फिर से एक विधि में निकाले), या यदि आप अभी कर सकते हैं कि कई प्रभाव हैं ' टी टेस्ट इन ए सिंगल (या अगर आपने किया तो यह स्पष्ट नहीं होगा कि यह क्यों विफल हुआ)

— शाफ़्ट फ्रीक

Answer 1

उचित इकाई परीक्षणों में एक नामकरण सम्मेलन होता है जो आपको तुरंत पहचानने में मदद करता है कि क्या विफल रहा है:

public void AddNewCustomer_CustomerExists_ThrowsException()

यही कारण है कि आपके पास प्रति परीक्षण एक जोर है, ताकि प्रत्येक विधि (और यह नाम है) उस स्थिति से मेल खाती है जिसे आप जोर दे रहे हैं।

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

TDD में, कोई भी परीक्षण YAGNI नहीं है, क्योंकि आप केवल अपने कोड के आधार पर परीक्षण लिखते हैं कि आपको क्या करने की आवश्यकता है। यदि आपको इसकी आवश्यकता नहीं है, तो आप परीक्षण नहीं लिखेंगे।

Comments

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

— कोरी हिंटन

अपने अंतिम बिंदु पर, मुझे यकीन है कि मैं परीक्षण कार्यक्षमता के लिए मैं चाहता हूँ लिख सकता हूँ की तरह कोड के लिए, बल्कि कार्यक्षमता की तुलना में यह जरूरत

— joelb

Answer 2

तो क्या एकल-परीक्षण परीक्षण DRY का उल्लंघन करता है?

नहीं, लेकिन यह उल्लंघन को बढ़ावा देता है।

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

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

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

मैं इसे सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल पर एक बदलाव के रूप में देखता हूं: केवल एक चीज होनी चाहिए, जिससे एक टेस्ट फेल हो सकता है और एक आदर्श दुनिया में केवल एक टेस्ट में बदलाव होना चाहिए।

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

Comments

परीक्षणों के लिए, डीआरवाई (वर्णनात्मक और सार्थक वाक्यांश) की तुलना में डीएएमपी होना अधिक महत्वपूर्ण है।

— जॉर्ग डब्ल्यू मित्तग

Answer 3

नहीं। ऐसा लगता है जैसे आप इसे कर रहे हैं। जब तक आपको एक उल्लेखनीय संदर्भ नहीं मिला, जहां वे दावा करते हैं कि यह एक अच्छा अभ्यास है।

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

आम तौर पर अपने कोड की संरचना के लिए आप जैसे तरीकों का उपयोग करें। जब रिफैक्टरिंग परीक्षण सामान्य टीडीडी रेड-ग्रीन-रिफैक्टर लागू नहीं होता है, इसके बजाय, "रिफैक्टिंग इन द रेड" लागू होता है। अर्थात्,

1. जानबूझकर अपना परीक्षण तोड़ो,
2. अपनी रिफ़ेक्टिंग करो
3. अपना परीक्षण ठीक करें

इस तरह आप जानते हैं कि परीक्षण अभी भी सकारात्मक और नकारात्मक परिणाम देते हैं।

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