क्या यूनिट परीक्षण को भंगुर माना जाता है यदि यह विफल हो जाता है जब व्यापार तर्क बदलता है?

Question

कृपया नीचे कोड देखें; यह देखने के लिए परीक्षण करता है कि क्या महिला के लिंग वाला व्यक्ति ऑफ़र 1 के लिए योग्य है:

[Fact]
public void ReturnsFalseWhenGivenAPersonWithAGenderOfFemale()
{
    var personId = Guid.NewGuid();
    var gender = "F";
    var person = new Person(personId, gender);

    var id = Guid.NewGuid();
    var offer1 = new Offer1(id,"Offer1");
    Assert.False(offer1.IsEligible(person));
}

यह इकाई परीक्षण सफल होता है। हालाँकि, यह विफल हो जाएगा अगर 'Offer1' भविष्य में महिलाओं को पेश किया जाता है।

क्या यह कहना स्वीकार्य है - यदि व्यावसायिक तर्क आसपास के प्रस्ताव 1 को बदलता है तो इकाई परीक्षण को बदलना होगा। कृपया ध्यान दें कि कुछ मामलों में (कुछ प्रस्तावों के लिए) इस तरह से डेटाबेस में व्यावसायिक तर्क बदल जाता है:

update Offers set Gender='M' where offer=1;

और इस तरह डोमेन मॉडल में कुछ मामलों में:

if (Gender=Gender.Male)
{
  //do something
}

कृपया यह भी ध्यान दें कि कुछ मामलों में प्रस्ताव के पीछे डोमेन तर्क नियमित रूप से बदलता है और कुछ मामलों में ऐसा नहीं होता है।

Comments

दूसरे कोण से सोचें: क्या आप परीक्षण करना चाहते हैं जो परीक्षण के तहत सिस्टम में तर्क बदलने पर विफल नहीं हुआ?

— Fabio

Answer 1

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

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

परीक्षण का नाम Returns False When Given A Person With A Gender Of Femaleएक व्यावसायिक नियम का वर्णन नहीं करता है। एक व्यापार नियम कुछ इस तरह होगा Offers Applicable to M should not be applied to persons of gender F।

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

Comments

@ जाकबी, तो यह एक इकाई परीक्षण नहीं होगा? या होगा? मेरा मानना ​​है कि यदि डेटाबेस शामिल था तो यह एक एकीकरण परीक्षण होगा। क्या वह सही है? क्या आप कह रहे हैं कि यूनिट लॉजिक का उपयोग न करें यदि व्यवसाय तर्क बहुत बदल जाता है?

— w0051977

@ w0051977: निर्भर करता है कि आप टेस्ट कैसे लिखते हैं। यदि परीक्षण में वास्तव में डेटाबेस में कुछ बदलना शामिल है, तो यह एक एकीकरण परीक्षण होगा।

— जैक्सबी

@ w0051977 बेहतर विचार - व्यावसायिक नियमों को लागू करने के लिए जिम्मेदार घटक की निर्भरता का भंडार नहीं होना चाहिए। एक उच्च-स्तरीय ऑर्केस्ट्रेशन है जो रिपॉजिटरी को कॉल करता है और फिर व्यावसायिक नियमों को लागू करता है। अब आप अलगाव में व्यावसायिक नियमों का परीक्षण कर सकते हैं।

— एंट पी

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

— एंट पी

@ w0051977 इस विचार को कुछ हद तक बढ़ाता है, यदि व्यावसायिक तर्क बदलते हैं या बग ठीक हो जाता है और परीक्षणों को समायोजित करने की आवश्यकता नहीं होती है, तो यह एक संकेत है कि परीक्षण पर्याप्त मामलों को कवर नहीं कर रहे हैं और आमतौर पर इसका विस्तार किया जाना चाहिए।

— मॉर्गन

Answer 2

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

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

आप परीक्षण को चलाने के लिए एक इकाई परीक्षण ढांचे का उपयोग कर सकते हैं। लेकिन यूनिट टेस्ट फ्रेमवर्क रनिंग यूनिट टेस्ट तक सीमित नहीं हैं। वे एकीकरण परीक्षण भी कर सकते हैं और कर सकते हैं।

आप एक इकाई परीक्षण लिख रहे थे, तो आप दोनों का सृजन होगा personऔर offer1डेटाबेस राज्य पर कोई निर्भरता के साथ जमीन से। कुछ इस तरह

[Fact]
public void ReturnsFalseWhenGivenAPersonWithAGenderOfFemale()
{
    var personId = Guid.NewGuid();
    var gender = "F";
    var person = new Person(personId, gender);

    var id = Guid.NewGuid();
    var offer1 = new Offer1(id, "ReturnsFalseWhenGivenAPersonWithAGenderOfFemale");
    offer1.markLimitedToGender("M");

    Assert.False(offer1.IsEligible(person));
}

ध्यान दें कि यह व्यावसायिक तर्क के आधार पर नहीं बदलता है। यह मुखर नहीं है कि offer1महिलाओं को खारिज कर दिया। यह offer1महिलाओं को अस्वीकार करने वाले प्रस्ताव का प्रकार बना रहा है।

आप परीक्षण के भाग के रूप में डेटाबेस बना और कॉन्फ़िगर कर सकते हैं। C # में, NUnit का उपयोग करके, या Java के JUnit में, आप डेटाबेस को एक Setupविधि में सेट करेंगे । संभवतः आपके परीक्षण ढांचे में एक समान धारणा है। उस पद्धति में, आप SQL के साथ डेटाबेस में रिकॉर्ड सम्मिलित कर सकते हैं।

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

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

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

TL; DR : आप इस तरह परीक्षण लिख सकते हैं, लेकिन आप अपने सॉफ़्टवेयर को लिखना बेहतर हो सकते हैं, इसलिए आपको ऐसा करने की आवश्यकता नहीं है।

Comments

मैं आपके उत्तर में कुछ मामूली विवरणों को सुधारने की स्वतंत्रता देता हूं। कृपया जांचें कि क्या मुझे आपके इरादे सही लगे।

— डॉक ब्राउन

मूल पोस्ट में एक डेटाबेस शामिल होने का कोई संकेत नहीं है। इसलिए यह दावा करते हुए कि यह मानता है कि ऑफ़र 1 डेटाबेस में पहले से ही विचित्र है।

— विंस्टन इर्वर्ट

@InstonEwert: एक स्पष्ट संकेत है, आपको प्रश्न को अधिक ध्यान से पढ़ना होगा। मुझे पहली बार पढ़ने पर भी इसका एहसास नहीं हुआ, लेकिन यह वास्तव में ओपी की बात कर रहा है।

— डॉक ब्राउन

@ mdfst13, मुझे खेद है कि मैं चूक गया। हालांकि, ओपी जो कह रहा है वह यह है कि स्थितियां कभी डेटाबेस में और कभी डोमेन मॉडल में होती हैं। आपका उत्तर पहले मामले के लिए पूरी तरह से ठीक है, और दूसरे में अपरिवर्तनीय रूप से। यदि आप उस बिंदु को स्पष्ट करने के लिए अपने उत्तर को संपादित करेंगे, तो मैं अपनी जल्दबाजी को हटा दूंगा।

— विंस्टन इर्वर्ट