Sinon: सैंडबॉक्स त्रुटि फेंकता है 'गैर-मौजूद अपनी संपत्ति को रोक नहीं सकता'

#1512 से संबंधित।

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

सुनिश्चित नहीं है कि हमें यहां क्या करना चाहिए। यह कहने के लिए डॉक्स अपडेट करें कि गैर-मौजूदा मानों को ठप करना कोई मतलब नहीं है और असमर्थित है, या इसे संभव बनाते हैं?

यदि संपत्ति मौजूद नहीं है, तो आपको इसे सैंडबॉक्स में जोड़ने की आवश्यकता नहीं है। बस इसे ओवरराइट करें।

सैंडबॉक्स में संपत्ति जोड़ने के बारे में अच्छी बात यह है कि सिनॉन तब मुझे अपने वैश्विक परीक्षण वातावरण को प्रत्येक परीक्षण के बीच sandbox.restore() माध्यम से साफ रखने में मदद करता है। यह एक अत्यंत उपयोगी विशेषता है, विशेष रूप से Google मानचित्र जैसे तृतीय पक्ष पुस्तकालयों से निपटने के दौरान जहां मैं एपीआई को नियंत्रित नहीं करता हूं। यह बहुत अच्छा होगा अगर इसे 3.x लाइन में काम करने के लिए बनाया जा सके।

साथ ही मैंने अभी देखा कि मैंने एक पूर्ण उदाहरण न देने का पाप किया है। मेरा सैंडबॉक्स 2.4.1 प्रारूप के साथ बनाया जा रहा है:

let sandbox;

before(() => { sandbox = sinon.sandbox.create(); })
afterEach(() => { sandbox.restore(); })

सुनिश्चित नहीं है कि यह महत्वपूर्ण है; जल्दी उपलब्ध नहीं कराने के लिए क्षमाप्रार्थी हूँ।

मुझे लगता है कि परिदृश्यों में जैसे @ZebraFlesh वर्णन करता है, मैं टेक्स्ट फिक्स्चर को और अधिक स्पष्ट करना पसंद करूंगा।

// not so explicit, doesn't work with [email protected]
beforeEach(function() {
    const spy = sandbox.spy();
    sandbox.stub(window, 'google').value({
        maps: {
            LatLng: x => x,
            Map: spy
        }
    }); 
});

// more explicit, works with sinon<strong i="9">@2</strong>, sinon<strong i="10">@3</strong>
function setGoogleMapsFixture(sandbox) {
    window.google = {
        maps: {
            LatLng: x => x,
            Map: sandbox.spy()
        }
    };
}

function removeGoogleMapsFixture() {
    delete window.google;
}

beforeEach(function() {
    setGoogleMapsFixture(sandbox)
});

// not using afterEach, as this only needs to happen
// after the last test in this block is run
after(function() {
    removeGoogleMapsFixture();
});

ऊपर उल्लिखित स्थिरता की अधिक स्पष्ट सेटिंग के साथ, आपको सिनॉन में एक ऐसी सुविधा की आवश्यकता नहीं है जो गैर-मौजूदा स्वयं के गुणों की स्टबिंग की अनुमति दे।

सुनिश्चित नहीं है कि हमें यहां क्या करना चाहिए। यह कहने के लिए डॉक्स अपडेट करें कि गैर-मौजूदा मानों को ठप करना कोई मतलब नहीं है और असमर्थित है, या इसे संभव बनाते हैं?

जबकि मैं मानता हूं कि यह कुछ परिदृश्यों में सुविधाजनक हो सकता है (जैसे कि @ZebraFlesh द्वारा वर्णित), मुझे लगता है कि गैर-मौजूदा स्वयं के गुणों को रोकने से परीक्षणों में गलतियां होने की संभावना है, जहां परीक्षण पास हो जाता है क्योंकि लेखक ने नाम गलत टाइप किया है मौजूदा संपत्ति जिसे वे रोकने का लक्ष्य बना रहे थे। हमें उन गलतियों की संभावना को खत्म करने का लक्ष्य रखना चाहिए जहां हम बहुत अधिक प्रतिबंधात्मक न हों।

मुझे लगता है कि गैर-मौजूदा स्वयं की संपत्तियों को रोकना असमर्थित रहना चाहिए। हमें दस्तावेज़ीकरण को अद्यतन करना चाहिए।

@mroderick मैं

तो या तो:

• इस ब्रेकिंग फीचर को ठीक करने के लिए सैंडबॉक्स के लिए चेक को तुरंत हटा दें

या और(?)

• सामान्य और सैंडबॉक्स वाले दोनों स्टब्स के लिए कार्यक्षमता को हटा दें
  
  
  
  • अद्यतन डॉक्स के साथ नया प्रमुख संस्करण जारी करें
  
  

ऊपर उल्लिखित स्थिरता की अधिक स्पष्ट सेटिंग के साथ, आपको सिनॉन में एक ऐसी सुविधा की आवश्यकता नहीं है जो गैर-मौजूदा स्वयं के गुणों की स्टबिंग की अनुमति दे।

मुझे लगता है कि यह अच्छा काम करता है यदि आपकी स्थिरता आपके परीक्षणों में कभी भिन्न नहीं होती है। हालांकि, मेरी स्थिरता करता है। एक सरल उदाहरण सफलता और विफलता दोनों मामलों को कवर कर रहा है:

it('handles the success case', () => {
        const spy = sandbox.spy();
        sandbox.stub(window, 'google').value({
            maps: {
                LatLng: x => x,
                Map: spy
            }
        });
        // ... test, including asserting that the spy was called
});

it('handles the failure case', () => {
        const msg = 'test error';
        sandbox.stub(window, 'google').value({
            maps: {
                LatLng: x => x,
                Map: sandbox.stub().throws(new Error(msg))
            }
        });
        // ... test, ignoring spy calls and instead focusing on error handling
});

2.x के व्यवहार में प्रत्येक परीक्षण के बाद sandbox.restore() माध्यम से सब कुछ ठीक से साफ होने का लाभ है। ऊपर उल्लिखित अधिक स्पष्ट स्थिरता सेटअप उदाहरण का उपयोग करते हुए, मुझे लगता है कि आप समान प्रभाव प्राप्त करने के लिए afterEach हुक में गैर-स्वयं की संपत्ति को हटा सकते हैं।

अनजाने में किसी मौजूदा संपत्ति का नाम टाइप करके संभावित गलतियों को पेश करने की समस्या को हल करने के लिए, सिनॉन सार्वजनिक एपीआई को संशोधित कर सकता है:

• stub.ownValue() : केवल अपनी संपत्तियों को स्टब्स करता है, गैर-स्वयं के गुणों के लिए फेंकता है
• stub.value() : केवल गैर-स्वयं के गुणों को स्टब्स करता है, स्वयं के गुणों के लिए फेंकता है

एपीआई अधिक स्पष्ट हो जाता है और उपभोक्ता को कार्य के लिए उपयुक्त उपकरण चुनने के लिए मजबूर किया जाता है।

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

अभी यह है स्थिति :

• सामान्य स्टब्स 1.x में फेंकते थे, लेकिन यह 2.0 में बदल गया और अब नहीं फेंकता
• सैंडबॉक्स फेंकने के लिए उपयोग नहीं करते थे, लेकिन 3.1 (?)

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

जबकि मैं असुविधा को समझता हूं, ऐसा लगता है कि न्यूनतम कोड परिवर्तनों के साथ एक आसान समाधान है।

before(function() {
  window.google = 'This is a placeholder for sinon to overwrite.';
});

after(function() {
  delete window.google;
});

यह सिनॉन कोड को अपरिवर्तित रहने की अनुमति देता है।

रिग्रेशन बनाम खराब दस्तावेज़ीकरण

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

@fearphage यथास्थिति बनाए रखने का अर्थ है कि गैर-मौजूदा फ़ील्ड को स्टब करना सैंडबॉक्स के लिए असमर्थित व्यवहार है, जबकि यह सामान्य स्टब्स के लिए समर्थित व्यवहार है। क्या यह थोड़ा दुर्भाग्यपूर्ण नहीं है कि दो फीचर सेट संरेखित नहीं होते हैं?

#1557 . में संकल्प लागू किया गया

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

मुझे लगता है कि टाइपस्क्रिप्ट शायद आप लोगों के लिए प्राथमिकता नहीं है, लेकिन जेएस में भी यह सहज ज्ञान युक्त लगता है कि myObject.callMe() पूरी तरह खुशी से निष्पादित होगा, जबकि sinon.stub(myObject, "callMe") उस मामले में नहीं होगा। मैं इस बात की जांच नहीं करना चाहूंगा कि उस विशेष वस्तु को एक साथ कैसे रखा गया था, इसलिए मुझे पता है कि इसे कैसे रोकना है।

मुझे वास्तव में लगता है कि जेएस में कक्षाओं को अधिक मूल समर्थन मिल रहा है, इस पर विचार करने के लिए यह एक महत्वपूर्ण उपयोग मामला है।

यदि आपको यह कहते हुए कोई त्रुटि मिलती है कि विधि वस्तु पर अपरिभाषित है, तो आप जानते हैं कि त्रुटि संभवतः प्रोटोटाइप है। फिर myObject.callMe = sinon.stub(); का उपयोग करके ऑब्जेक्ट को सीधे संशोधित करना IMHO के लिए इतनी परेशानी की तरह प्रतीत नहीं होता है ... आपको क्लीनअप/टियरडाउन फ़ंक्शन बनाने से भी बचाना चाहिए, क्योंकि प्रोटोटाइप कभी नहीं बदला गया था।

हाँ, मुझे लगता है कि काम करना बहुत मुश्किल नहीं है, यह सिर्फ मुझ पर अधिक संज्ञानात्मक भार डाल रहा है कि चीजों को कैसे लागू किया जाता है।

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

~इस व्यवहार को बहाल करने के लिए धन्यवाद।~

एक ऐसा उपयोग मामला जोड़ना चाहता था जो अस्तित्वहीन गुणों को रोकने का समर्थन करता हो।

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

sandbox.stub(serverSecrets, 'the_key_i_need_set').value(fakeValue) यह बताने का एक बहुत ही स्पष्ट तरीका है। यह अच्छा है कि मुझे वही व्यवहार मिलता है, _भले ही मुझे रनटाइम पर पता न हो कि कुंजी सेट है या नहीं।