दिए गए, जब, कार्यान्वयन में विश्वास और विश्वास

अभिकथन के बारे में अंतिम पाठ में , कुछ महत्वपूर्ण गायब था और सहमति नहीं थी।

दिए गए के बीच अंतर क्या है और यह कब और कैसे संबंधित है?

यह अंतर्निहित विचार सरल है - हम दावे की संख्या को सीमित करना चाहते हैं।

एक छोटे से उदाहरण पर विचार करें।

आइए हम विधि में कुछ वैध ऑब्जेक्ट पास करते हैं, अतिरिक्त सेवा को कॉल करते हैं और इसके गुणों को समृद्ध करते हैं।

मुझे परीक्षण के आगे कोड लिखने की ज़रूरत नहीं है, इसलिए हम मानेंगे कि यह केवल बड़ी तस्वीर बताने के लिए है।

public User enrichUser(User validUser){ user.setDetails(enrichmentService.getUserDetails(validUser.getId())); return user; } 

हम वैध भिन्नताओं में रुचि नहीं रखते हैं। यह शून्य नहीं है, इसमें हमेशा एक आईडी है, फिर यह वैध है। यह पूर्वधारणा है, अर्थात् दिए गए।

वास्तव में, हमें दो स्थितियों पर विचार करने की आवश्यकता है - संवर्धन सेवा विफल और सफलता। यह एक शर्त है, अर्थात्। जब।

एक को दूसरे से अलग कैसे करें? दिए जाने पर अन्य मामलों के सत्यापन की आवश्यकता नहीं होती है, जब - आवश्यकता होती है। यानी जबValidUser की आवश्यकता होती है जब InvalidUser, और दिए गएValidUser नहीं होते हैं।

और संवर्धन सेवा == अशक्त? यदि हमने एक निर्भरता को इंजेक्ट किया है, तो हम कॉन्फ़िगरेशन के इस हिस्से पर विचार कर सकते हैं और परीक्षणों में इसके बारे में नहीं सोच सकते हैं। निश्चित रूप से। ऐसी पूर्वधारणाएँ हैं कि यह सूची के लिए कोई मतलब नहीं है

यदि विधि सिर्फ उपयोगकर्ता को स्वीकार करती है, तो जाँच की जा रही स्क्रिप्ट की संख्या बढ़ जाती है। जब दिया जाता है।

एक और सवाल - लेकिन, सख्ती से, दुर्घटना से या जानबूझकर, एक विधि हमारे लिए एक उपयोगकर्ता को बर्बाद कर सकती है? क्या हमें इसकी जाँच नहीं करनी चाहिए?

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

हवाई अड्डे की सुरक्षा के साथ इसकी तुलना की जा सकती है - कोई टिकट चेक करता है, कोई सामान, कोई जेब, और चेक हर कदम पर नकल नहीं करता है। यानी यह विश्वास दिलाता है कि कार्यान्वयन क्या करेगा, और केवल वही जाँचें जो वे लिखते हैं।

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

दुर्भाग्य से, ककड़ी जैसी रूपरेखाओं से बहुत फर्क नहीं पड़ता है, क्योंकि प्रीकॉन्डिशन खुद उनके लिए यह नहीं देखते हैं कि यह देखते हुए, कि कब एक ही है, विशुद्ध रूप से वर्णनात्मक शब्द।

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

विनिर्देशों के पुनर्गठन और पुन: डिज़ाइन करने का यह एक अच्छा कारण है।