यूनिट टेस्टिंग: "यदि आप रिफैक्टिंग कर रहे हैं और कोई सहयोगी नहीं हैं तो यह एक कोड गंध है"?

9

मैं रॉय ओशेरोव द्वारा द आर्ट ऑफ यूनिट टेस्टिंग पढ़ रहा हूं। मैं खंड at.२ में लेखन योग्य परीक्षण लिख रहा हूं जहां लेखक के पास कोड गंध के बारे में यह नोट है:

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

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

एक स्टब सिस्टम में मौजूदा निर्भरता (या सहयोगी ) के लिए एक नियंत्रणीय प्रतिस्थापन है।

लेखक के पास इस कोड की गंध का उदाहरण नहीं है और मुझे यह समझने में परेशानी हो रही है कि यह कैसा दिखेगा। क्या कोई इसे थोड़ा और समझा सकता है और शायद एक ठोस उदाहरण प्रदान कर सकता है?

unit-testing code-quality code-smell

— प्रोग्रामर
स्रोत

मुझे लगता है कि यहाँ भ्रम "Collaborators" शब्द से उपजा है। मुझे यह मानना चाहिए कि मुझे इस संदर्भ में कोई मतलब नहीं है।

— रासपेडिया

@ ब्रायन रॉस, मैंने पोस्ट को अपडेट किया कि लेखक "सहयोगी" शब्द का उपयोग कैसे करता है। धन्यवाद!

— प्रोग्रामर

3

मुझे लगता है कि यह वही है जो लेखक को मिल रहा है।

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

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

डबल outputको एक्सपोज़ करना एक कोड गंध होगा क्योंकि यह एक सहयोगी नहीं है - यह स्पष्ट रूप से वर्ग द्वारा छिपाया गया एक तत्व है जो यह GetOutputनिर्धारित करने के लिए सशर्त तर्क है कि क्या लौटाया जाना चाहिए।

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

सार्वजनिक वर्ग TimeWindow
{
  निजी बूल है।
  निजी बूल spansMnight;
  निजी TimeSpan start1;
  निजी TimeSpan stop1;
  निजी TimeSpan start2;
  निजी TimeSpan stop2;
  निजी डबल आउटपुट;

  सार्वजनिक TimeWindow (डबल आउट, टाइमस्पैन प्रारंभ, टाइमस्पैन स्टॉप)
  {
    आउटपुट = बाहर;

    अगर (स्टार्ट == स्टॉप)
      isConst = true;
    और अगर (शुरू> बंद)
    {
      spansMidnight = true;
      start1 = आधी रात;
      stop1 = रोक;
      start2 = start;
      stop2 = आधी रात;
    }
    अन्य 
    {
      start1 = start;
      stop1 = रोक;
    }
  }

  सार्वजनिक डबल गेटऑउटपुट (टाइमस्पैन समय)
  {
    // यहाँ क्या / कैसे लौटना है कुछ तर्क
    ...
    वापसी उत्पादन;
  }

}

0

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

अब, यह एक डोमेन वर्ग होने के नाते, इसमें राज्य डेटा है। आइए एक पल के लिए मान लें कि किसी एक स्टेटफुल प्रॉपर्टी का बैकिंग फील्ड है, और प्रॉपर्टी ऐक्सेसर्स टेस्ट करते हैं कि करंट के आधार पर एक नया इनपुट वैलिड है (हो सकता है कि नया वैल्यू कभी भी पुराने से कम न हो)। आपको इस सत्यापन का परीक्षण करने की आवश्यकता है, लेकिन आप पाते हैं कि ऐसा करने के लिए एक प्रारंभिक मान सेट करने के लिए बैकिंग फ़ील्ड तक पहुंच की आवश्यकता होती है जिसे आप फिर से अधिलेखित करने का प्रयास करेंगे। यह एक लाल झंडा होना चाहिए; यदि परीक्षण को बैकिंग फ़ील्ड तक पहुंच की आवश्यकता होती है (जो एक कार्यान्वयन विवरण है, तो कोई भी उपभोक्ता कभी भी नहीं होना चाहिएएक परीक्षण के लिए एक सुसंगत स्थिति में वस्तु प्राप्त करने के लिए यह जानना है), फिर उत्पादन कोड को एक सुसंगत वस्तु कैसे मिलेगी? अगर उत्पादन कोड के लिए एक विधि है जो आपके परीक्षण में वही काम करता है, तो परीक्षण को संभवतः उस तरह की नकल करनी चाहिए। यदि इस राज्य में ऑब्जेक्ट प्राप्त करने के लिए उत्पादन कोड के लिए कोई वैध तरीका नहीं है, तो आप इस परिदृश्य का परीक्षण क्यों कर रहे हैं?

— Keiths
स्रोत