मैं एक ऐसी प्रणाली का परीक्षण कैसे कर सकता हूं जहां वस्तुओं का मजाक उड़ाना मुश्किल है?

Question

मैं निम्नलिखित प्रणाली के साथ काम कर रहा हूं:

Network Data Feed -> Third Party Nio Library -> My Objects via adapter pattern

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

समस्या:

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

समस्या यह है, मैं इन डेटा संरचनाओं में निहित डेटा के बारे में सुनिश्चित नहीं हो सकता क्योंकि मैं वास्तविक डेटा फ़ीड के बिना वास्तविक उत्पन्न नहीं कर सकता। ये ऑब्जेक्ट बड़े और जटिल हैं और उनमें डेटा के बहुत सारे टुकड़े हैं। तीसरे पक्ष के पुस्तकालय के लिए प्रलेखन खराब है।

प्रश्न:

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

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

Comments

क्या आपका "वास्तविक डेटा फीड" रिकॉर्ड कर सकता है और बाद में इसे थर्ड पार्टी लाइब्रेरी में "प्ले" कर सकता है?

— इदन आर्य 15

कोई इस तरह की समस्याओं पर एक किताब लिख सकता है। वास्तव में, माइकल फेयर्स ने सिर्फ उस पुस्तक को लिखा: c2.com/cgi/wiki?WorkingEffectivelyWithLegacyCode इसमें, उन्होंने कठिन निर्भरता को तोड़ने के लिए कई तकनीकों का वर्णन किया है ताकि कोड अधिक विश्वसनीय बन सके।

— cbojar

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

— jpmc26

बिल्ट-इन की बुराई का एक आदर्श चित्रण। क्यों पुस्तकालय एक वापस नहीं करता Timestampवर्ग (किसी भी प्रतिनिधित्व वे चाहते हैं) और प्रदान नामित विधियों ( .seconds(), .milliseconds(), .microseconds(), .nanoseconds()) और पाठ्यक्रम नामित निर्माताओं की। तब कोई मुद्दा नहीं रहा होगा।

— मैथ्यू एम।

कहावत "कोडिंग में सभी समस्याओं को अप्रत्यक्ष की एक परत द्वारा हल किया जा सकता है (सिवाय, निश्चित रूप से, अप्रत्यक्ष की कई परतों की समस्या)" यहां ध्यान में आता है ..

— दान पैंट्री

Answer 1

ऐसा लगता है कि आप पहले से ही परिश्रम कर रहे हैं। परंतु ...

सबसे व्यावहारिक स्तर पर, हमेशा अपने स्वयं के कोड के लिए अपने सूट में "पूर्ण-लूप" एकीकरण परीक्षणों के एक अच्छे मुट्ठी भर को शामिल करें, और जितना आवश्यक हो आपको लगता है कि तुलना में अधिक जोर दें। विशेष रूप से, आपके पास कुछ मुट्ठी भर परीक्षण होने चाहिए जो एक पूर्ण बनाएँ-रीड करते हैं- [do_stuff] -validate चक्र।

[TestMethod]
public void MyFormatter_FormatsTimesCorrectly() {

  // this test isn't necessarily about the stream or the external interpreter.
  // but ... we depend on them working how we think they work:
  var stream = new StreamThingy();
  var interpreter = new InterpreterThingy(stream);
  stream.Write("id-123, some description, 12345");

  // this is what you're actually testing. but, it'll also hiccup
  // if your 3rd party dependencies introduce a breaking change.
  var formatter = new MyFormatter(interpreter);
  var line = formatter.getLine();
  Assert.equal(
    "some description took 123.45 seconds to complete (id-123)", line
  );
}

और ऐसा लगता है कि आप पहले से ही इस तरह का काम कर रहे हैं। आप बस एक परतदार और / या जटिल पुस्तकालय के साथ काम कर रहे हैं। और उस मामले में, कुछ में फेंकना अच्छा है "यह है कि पुस्तकालय कैसे काम करता है" प्रकार के परीक्षण जो दोनों पुस्तकालय की आपकी समझ को सत्यापित करते हैं और लाइब्रेरी का उपयोग करने के तरीके के रूप में सेवा करते हैं।

मान लें कि आपको समझने और इस बात पर निर्भर करने की आवश्यकता है कि JSON पार्सर JSON स्ट्रिंग में प्रत्येक "प्रकार" की व्याख्या कैसे करता है। अपने सुइट में ऐसा कुछ शामिल करना सहायक और तुच्छ है:

[TestMethod]
public void JSONParser_InterpretsTypesAsExpected() {
  String datastream = "{nbr:11,str:"22",nll:null,udf:undefined}";
  var o = (new JSONParser()).parse(datastream);

  Assert.equal(11, o.nbr);
  Assert.equal(Int32.getType(), o.nbr.getType());
  Assert.equal("22", o.str);
  Assert.equal(null, o.nll);
  Assert.equal(Object.getType(), o.nll.getType());
  Assert.isFalse(o.KeyExists(udf));
}

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

और एक महत्वपूर्ण डिग्री के लिए, यह सिर्फ सामान्य है।

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

Comments

उह, मैं चाहता हूं कि यह पुस्तकालय में एक जौन स्ट्रिंग को खिलाने के रूप में सरल था। यह। मैं इसके बराबर नहीं कर सकता (new JSONParser()).parse(datastream), क्योंकि वे डेटा को सीधे से हड़प लेते हैं NetworkInterfaceऔर सभी वर्ग जो वास्तविक पार्सिंग करते हैं, पैकेज निजी और पहरेदार होते हैं।

— डुर्रोन 597

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

— डुर्रोन 597

@ Durron597 ओह, यह लगभग कभी नहीं है। लेकिन, आप अक्सर अंतर्निहित डेटा स्रोत को नकली कर सकते हैं - जैसे पहले कोड उदाहरण में। ... बिंदु यह है: जब संभव हो तो फुल-लूप एकीकरण परीक्षण करें, संभव होने पर पुस्तकालय की अपनी समझ का परीक्षण करें, और बस इस बात से अवगत रहें कि आप अभी भी कीड़े को जंगली में जाने देंगे । और आपके तीसरे पक्ष के विक्रेताओं को अदृश्य, ब्रेकिंग परिवर्तन करने के लिए जवाबदेह होना चाहिए।

— svidgen

@ durron597 मैं इससे परिचित नहीं हूं NetworkInterface... क्या यह कुछ है जो आप इंटरफ़ेस को लोकलहोस्ट या कुछ पर पोर्ट से कनेक्ट करके डेटा फीड कर सकते हैं?

— svidgen

NetworkInterface। यह सीधे एक नेटवर्क कार्ड के साथ काम करने और उस पर सॉकेट खोलने आदि के लिए निम्न स्तर की वस्तु है,

— ड्यूर्रोन 597

Answer 2

संक्षिप्त उत्तर: यह कठिन है। आप शायद महसूस कर रहे हैं कि कोई अच्छे उत्तर नहीं हैं, और ऐसा इसलिए है क्योंकि कोई आसान उत्तर नहीं हैं।

लंबे उत्तर: जैसे @ खाली कहते हैं , आपको सिस्टम परीक्षणों और एकीकरण परीक्षणों के साथ-साथ इकाई परीक्षणों की भी आवश्यकता है:

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

कुछ विशिष्ट सुझाव:

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

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

Answer 3

मैंने लाइब्रेरी के संस्करण को अपडेट किया ... जो ... टाइमस्टैम्प (जो तीसरे पक्ष के पुस्तकालय के रूप में लौटता है long) के कारण, युगों के बाद के युग से नैनोसेकंड के बाद मिलीसेकंड से बदला जाना है।

...

यह लाइब्रेरी में बग नहीं है

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

मान लीजिए कि इसके बजाय पुस्तकालय ने एक प्रकार का MillisecondsSinceEpoch, एक साधारण आवरण जो लौटाया है a long। जब उन्होंने इसे एक NanosecondsSinceEpochमूल्य में बदल दिया , तो आपका कोड संकलित करने में विफल रहा होगा, और स्पष्ट रूप से आपको उन स्थानों की ओर इशारा किया होगा जहां आपको बदलाव करने की आवश्यकता है। परिवर्तन चुपचाप आपके कार्यक्रम को दूषित नहीं कर सका।

बेहतर अभी तक एक ऐसी TimeSinceEpochवस्तु होगी जो इसे अनुकूल बना सकती है क्योंकि इंटरफ़ेस अधिक सटीक जोड़ा गया था, जैसे कि #toLongNanosecondsविधि के साथ एक विधि जोड़ना #toLongMilliseconds, आपके कोड में कोई भी बदलाव की आवश्यकता नहीं है।

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

Comments

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

— कोबजार

@ जीबीजैनब, "कि उनकी ख़राब रिलीज़ प्रथा है" मेरे लिए एक बग की तरह लगता है

— आर्टुरो टॉरेस सैंचेज़

@gbjbaanb एक 3-पक्षीय पुस्तकालय को अपने उपयोगकर्ताओं के साथ "अनुबंध" करना चाहिए। उस अनुबंध को तोड़ना - चाहे वह दस्तावेज हो या न हो - बग के रूप में होना चाहिए। जैसा कि दूसरों ने कहा है, अगर आपको कुछ बदलना चाहिए , तो एक नए फ़ंक्शन / विधि के साथ अनुबंध में जोड़ें (cf. सभी ...Ex()विधियों में Win32API)। यदि यह संभव नहीं है, तो फ़ंक्शन (या इसके रिटर्न प्रकार) का नाम बदलकर अनुबंध को "तोड़ना" व्यवहार को बदलने से बेहतर होता।

— ट्रीपहाउंड

यह लाइब्रेरी में एक बग है। एक लंबे समय में नैनोसेकंड का उपयोग इसे आगे बढ़ा रहा है।

— जोशुआ

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

— कोबजार

Answer 4

आपको एकीकरण और सिस्टम परीक्षण की आवश्यकता है।

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

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

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

Answer 5

सबसे अच्छा यह होगा कि एक न्यूनतम प्रोटोटाइप बनाया जाए, और समझा जाए कि लाइब्रेरी कैसे काम करती है। ऐसा करने से, आप लाइब्रेरी के बारे में कुछ ज्ञान प्राप्त करेंगे, जो खराब प्रलेखन के साथ है। एक प्रोटोटाइप एक न्यूनतम कार्यक्रम हो सकता है जो उस लाइब्रेरी का उपयोग करता है और कार्यक्षमता करता है।

अन्यथा, आधे-परिभाषित आवश्यकताओं और प्रणाली की कमजोर समझ के साथ, यूनिट परीक्षणों को लिखने का कोई मतलब नहीं है।

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

Answer 6

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

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

Comments

यह वास्तव में इस सवाल का जवाब नहीं देता है। मेरे पास पहले से ही लाइब्रेरी को मेरे सिस्टम से अलग करने वाली एक लेयर है, लेकिन समस्या यह है कि मेरे एब्सट्रैक्शन लेयर में "बग" हो सकते हैं, जब लाइब्रेरी मुझ पर बिना किसी चेतावनी के बदल जाती है।

— डुर्रोन 597

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

— कोबजार

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

— माइक नाइस

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

— माइक नाइस