Sinon: अन्यथा 2.0 रिलीज

/docs में पहले से मौजूद काम के आधार पर मैं एक नई दस्तावेज़ीकरण वेबसाइट बनाना चाहता हूं। मैं अगले सप्ताह अपनी छुट्टी के दौरान उस पर कुछ घंटे बिताने की उम्मीद कर रहा हूं।

@mroderick अगर आपके पास कहीं काम है, तो मुझे बताएं। मैं डॉक्स के साथ मदद करने में सक्षम हो सकता हूँ!

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

@jonnyreeves : निश्चित नहीं है कि हमें sinon.test क्यों निकालना चाहिए। यह परीक्षण के चारों ओर एक सैंडबॉक्स है जो किसी भी बनाए गए स्टब्स को साफ करता है और परीक्षण के बाद स्वचालित रूप से जासूसी करता है। यह लोगों को बहुत सारे beforeEach और afterEach कार्यों से राहत देता है। बहुत उपयोगी है, और परीक्षण ढांचे के साथ इसका कोई लेना-देना नहीं है।

उपयोगकर्ताओं को इसके लिए एक आसान विकल्प देखने की आवश्यकता होगी ताकि इसे किसी और चीज़ (बेहतर) के पक्ष में हटाया जा सके।

मैंने कभी भी sinon.testCase उपयोग नहीं किया है, शायद इसलिए कि इसका एपीआई बस्टरजेएस (जहां प्रत्येक टेस्ट केस टेस्ट सूट की संपत्ति है) फिट बैठता है और मोचा नहीं (जहां प्रत्येक परीक्षण टेस्ट सूट के शरीर में चल रहा एक अज्ञात कार्य है )

@ fatso83 मेरे पास sinon.test साथ मुख्य मुद्दा यह है कि यह sinon.config सिंगलटन पर निर्भर करता है। IMHO उपयोगकर्ता अपने परीक्षण-ढांचे के beofreEach और afterEach हुक में एक सैंडबॉक्स बनाकर (और पुनर्स्थापित) करके अधिक नियंत्रण प्राप्त कर सकते हैं।

अगर हम सार्वजनिक एपीआई में sinon.test (और sinon.testCase ) रखने जा रहे हैं; तो हमें इन दोनों मुद्दों को संबोधित करने की आवश्यकता है - हालांकि लंबे समय से उपयोगकर्ता / सिनॉन का समर्थन, मैं उनकी परियोजना पर हैकिंग के लिए नया हूं - हमें सहमति तक कैसे पहुंचना चाहिए?

@jonnyreeves ठीक है, जब आपने इसका उल्लेख किया तो यह अधिक समझ में आया sinon.config । IMHO स्पष्ट रूप से सैंडबॉक्स बनाना और पुनर्स्थापित करना ठीक है जब तक हम इसे सिनॉन 1 से आने वाले लोगों के लिए एक विकल्प के रूप में आपूर्ति करते हैं और सोचते हैं कि sinon.test क्या हुआ। तो doucmentation कुछ इस तरह पढ़ना चाहिए

sinon.test

_यह स्पष्ट रूप से सैंडबॉक्स बनाने के पक्ष में संस्करण 2 में बहिष्कृत कर दिया गया है। देखें link to sandbox ._

मैं संस्करण 2 में एक दुबला एपीआई के लिए तैयार हूं, इसलिए typeOf , extends और sinon.test* जैसी चीजें अन्य एनपीएम मॉड्यूल या अन्य मौजूदा कार्यक्षमता द्वारा बेहतर सेवा दी जा सकती हैं।

मुझे लगता है कि npm install sinon-test और var sinonTest = require('sinon-test')(config); जैसा कुछ एक अच्छा प्रतिस्थापन हो सकता है।

:+1: इस तरह की उपयोगिताओं को अलग-अलग npm मॉड्यूल में स्थानांतरित करने के लिए। core में कम कोड

इनपुट के लिए धन्यवाद; मैंने अब तक की चर्चा को दर्शाने के लिए ओवरव्यू को अपडेट किया है (मुख्य रूप से प्रश्न चिह्नों को हटाकर, कार्यों को स्पष्ट करना), कृपया एक नज़र डालें।

इसके अलावा, क्या हम इस पर समान बंद कर सकते हैं:

• sinon.log और sinon.logError को हटा रहा है (दोनों नकली_सर्वर द्वारा उपयोग किए जाते हैं; और शायद उन उदाहरणों के लिए कॉन्फ़िगरेशन के रूप में बेहतर पारित किया जाएगा)
• 2.0 . से sinon.mock हटा रहा है

धन्यवाद

मैंने कभी भी sinon.testCase उपयोग नहीं किया, हालांकि मैं sinon.test का भारी उपयोगकर्ता हूं। मैं इसके साथ एक अलग पुस्तकालय में जाने के साथ ठीक हूं, लेकिन बस यह नहीं भूलना चाहिए: परीक्षण ढांचे का उपयोग करने वाले कुछ लोग हैं जो beforeEach डिज़ाइन द्वारा (जैसे टेप) का समर्थन नहीं करते हैं, इस तर्क के साथ कि ये सेटअप कार्य युग्मित परीक्षण मामलों की ओर ले जाते हैं। यदि ड्रॉप-इन प्रतिस्थापन के लिए कोई आसान नहीं है, तो हम इन उपयोगकर्ताओं के लिए बहुत सी समस्याएं पैदा कर सकते हैं।

मुझे लगता है कि हम माइग्रेशन पथ के रूप में कुछ इस तरह पेश कर सकते हैं:

sinon.test = require('sinon-test');

@ मंटोनी : बढ़िया सुझाव। केवल अब अप्रयुक्त test संपत्ति को असाइन करके यह लोगों को उनके परीक्षणों में केवल एक अतिरिक्त लाइन शामिल करके कम से कम परेशानी देता है। हमें बस यह सुनिश्चित करना है कि किसी बिंदु पर sinon वस्तु जमी नहीं है (जैसे Object.freeze(sinon) ) ...

@jonnyreeves : sinon.mock मुझे याद है कि @mroderick ने इसे हटाने से पहले 2.0 जारी होने तक प्रतीक्षा करने का सुझाव दिया था। हमने पहले ही कुछ समय के लिए संकेत दिया है कि इसे बहिष्कृत कर दिया गया है, इसलिए 2.0 रिलीज आईएमएचओ के बाद इसे हटाना ठीक होगा। लेकिन चूंकि हमारे पास पहले से ही कॉमनजेएस समर्थन है, इसलिए मुझे 2.0 रिलीज _if_ से पहले इसे हटाने में कोई दिक्कत नहीं होगी, हमने कोड को अपने मॉड्यूल में निकाला है। तब लोग केवल let sinon.mock = require('sinon-mock') , यदि वे बहुत प्रसन्न हों।

के संबंध में sinon.log* , मुझे सार्वजनिक सुविधाओं के रूप में उन पर चिपके रहने का कोई कारण नहीं दिखता है यदि हम जरूरत पड़ने पर उन्हें केवल कॉन्फ़िगरेशन के रूप में आपूर्ति कर सकते हैं।

WRT एक sinon-test फैक्टरिंग करता है, बस ध्यान दें कि हमें उपभोक्ताओं को एक कॉन्फ़िगरेशन की आपूर्ति करने की अनुमति देने की आवश्यकता होगी, अर्थात:

sinon.test = require('sinon-test').withConfig({ ... });

या इसी के समान।

sinon-test पैकेज बनाते समय एक और संभावित API परिवर्तन देखा; sinon.assert का क्या होना चाहिए इसके बारे में कोई विचार? फिर से यह मेरे लिए सिनॉन एपीआई के मुख्य भाग की तरह महसूस नहीं करता है और sinon-test पैकेज के साथ sinon.test और sinon.testCase साथ माइग्रेट करके बेहतर अनुकूल हो सकता है?

@ fatso83 @mantoni @cjohansen; मेरे पास समीक्षा के लिए तैयार sinon-test पैकेज का एक कामकाजी निर्माण है - क्या आप में से कोई एक खाली गिट रेपो को sinonjs/sinon-test कर सकता है ताकि मैं इसके खिलाफ पीआर बढ़ा सकूं?

धन्यवाद

यह जल्दी था! https://github.com/sinonjs/sinon-test

@cjohansen क्या आप कृपया इसे एक खाली दे सकते हैं? ऐसा लगता है कि मैं वर्तमान स्थिति में जनसंपर्क नहीं बढ़ा सकता।

किया हुआ

धन्यवाद, पीआर उठाया - प्रतिक्रिया का स्वागत है: https://github.com/sinonjs/sinon-test/pull/1

@mroderick अगर आपके पास कहीं काम है, तो मुझे बताएं। मैं डॉक्स के साथ मदद करने में सक्षम हो सकता हूँ!

@spinningarrow जो बहुत अच्छा होगा। मैंने इसे बाकी प्रयासों से अलग ट्रैक करने के लिए #991 बनाया है। मैं आने वाले दिनों में इसे अपने विचारों के साथ अपडेट करूंगा, और हम इसे वहां से ले सकते हैं।

मॉक से संबंधित हमारे पास समय-समय पर कुछ समस्याएं आ रही हैं। अब जब @jonnyreeves ने वास्तव में मॉड्यूल को निकालने का कड़ी मेहनत की है, तो क्या मॉड्यूल को रेपो में स्थानांतरित करने का कोई मतलब नहीं होगा? तब हम केवल नकली से संबंधित सभी चर्चाओं को वहां स्थानांतरित कर सकते थे, और मुद्दों को यहां बंद कर सकते थे। यह मुख्य रूप से सिर्फ प्रशासन के बोझ को कम करने के लिए है।

मॉक से संबंधित हमारे पास समय-समय पर कुछ समस्याएं आ रही हैं। अब जब @jonnyreeves ने वास्तव में मॉड्यूल को निकालने का कड़ी मेहनत की है, तो क्या मॉड्यूल को रेपो में स्थानांतरित करने का कोई मतलब नहीं होगा? तब हम केवल नकली से संबंधित सभी चर्चाओं को वहां स्थानांतरित कर सकते थे, और मुद्दों को यहां बंद कर सकते थे। यह मुख्य रूप से सिर्फ प्रशासन के बोझ को कम करने के लिए है।

इसका मतलब यह भी होगा कि उस रिपॉजिटरी को देव टूल्स आदि के साथ सिंक में रखने का प्रशासन का बोझ।
शायद हमें यह सुनिश्चित करना चाहिए कि हमारे पास पहले आसान साझा किए गए देव उपकरण हैं? cc: @mantoni

@mroderick @fatso83 ठीक है, देखते हैं कि क्या हम 2.0 को दरवाजे से बाहर निकाल सकते हैं।

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

इसके अतिरिक्त, मैं निम्नलिखित पर सर्वसम्मति प्राप्त करना चाहता हूं:

1. क्या हमें सार्वजनिक ( sinon. ) एपीआई से typeOf और extend हटा देना चाहिए, या इसे सिनॉन 3.x की प्रतीक्षा करनी चाहिए जो (मुझे लगता है) एपीआई के आधुनिकीकरण से गुजरेगा। .
2. क्या हमें 2.0 से विरासती IE समर्थन/हैक्स को हटा देना चाहिए? यह _may_ माइग्रेशन को आसान बनाता है क्योंकि हम 'fakeXDM' कोड को छोड़ सकते हैं - मैंने करीब से नहीं देखा है इसलिए मैं अभी तक इस काम का अनुमान नहीं लगा सकता।
3. क्या नई डॉक्स साइट की शिपिंग 2.0 रिलीज़ की एक शर्त है? मुझे चिंता है कि इसमें बहुत अधिक कर्षण नहीं है :)

सबको शुक्रीया।

@jonnyreeves : आप निश्चित रूप से आज रात एक व्यस्त मधुमक्खी रहे हैं। मेरे आगे एक लंबी छुट्टी है, इसलिए मैं निश्चित रूप से परीक्षण सूट के उत्कृष्ट प्रवास में मदद कर सकता हूं (नीचे एक "लेकिन" है)।

आपके अंक के संबंध में:

1. उन्हें जाना चाहिए। मैंने सोचा कि यह काफी व्यवस्थित था (रेफरी, ऊपर का अवलोकन)।
2. आइए पहले "विरासत आईई" को परिभाषित करें। संस्करण <10, या संपूर्ण sinon-ie पैकेज? IE9 अभी भी XDR नामक कुछ अजीब CORS विकल्प के साथ शिपिंग कर रहा था। अगर कोई अभी भी 2012 से पहले जारी आईई संस्करणों का समर्थन करने का लक्ष्य रखता है तो वे हमेशा 1.x शाखा का उपयोग कर सकते हैं, मुझे लगता है। सुनिश्चित नहीं हैं कि आप एक्सडीएम द्वारा क्या संदर्भित करते हैं? मुझे यकीन नहीं है कि किस ब्राउज़र संस्करण के लिए sinon-ie की आवश्यकता है, इसलिए मैं पैकेज की आवश्यकता नहीं होने के बारे में बहुत अधिक बमबारी नहीं कर सकता। हमें परिणामों के बारे में निश्चित होना चाहिए।
3. दस्तावेज़ीकरण _is_ अभी एक दर्द बिंदु है, लेकिन मैं थोड़ा अनिश्चित हूं कि यहां क्या कहना है। मैं उपरोक्त अन्य बिंदुओं के साथ मदद करने से पहले #991 में खुदाई शुरू कर सकता था। डॉक्स को आगे बढ़ाने के लिए कहीं और होने से जीवन बेहतर हो जाएगा।

जिज्ञासुः इस पर क्या स्थिति है? ऐसा नहीं लगता कि ~6mo पहले के बाद से बहुत प्रगति हुई है; मैं वर्तमान में विभिन्न कारणों से पूर्व-रिलीज़ पर निर्भर हूं (प्रतीक का समर्थन बहुत बड़ा है) - मेरा मतलब धक्का देना नहीं है, लेकिन एक सरल 'एक हैसमयरेखा' / 'अभी तक कोई समयरेखा नहीं है' बहुत अच्छा होगा! <3

@ELLIOTTCABLE चूंकि हमारे पास फंडिंग नहीं है, इसलिए कोई समय सीमा निर्धारित नहीं है। यह प्रगति करता है क्योंकि हम अनुरक्षक समूह में - या अन्य स्वयंसेवकों जैसे कि आपके पास - ऊपर दी गई सूची पर काम करने के लिए समय है। ऐसा कहा जा रहा है, मुझे लगता है कि यदि आप थोड़ा और अधिक प्रहार करने की जहमत उठाते हैं तो आप स्वयं "स्थिति" का उत्तर दे सकते हैं :

1. भले ही आप ऊपर "... 8 जुलाई 2016 को संदर्भित" देखें, इसका मतलब केवल यह है कि सूची में पहली टिप्पणी उस तारीख की है। नवीनतम अंक, #1235, ने इसे "12 दिन पहले" संदर्भित किया।
2. मुद्दों की सूची लगभग पूर्ण है - आधे साल पहले के विपरीत।

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

मूल रूप से, ऊपर दी गई सूची को देखने के बाद केवल दो मुख्य मुद्दे रह जाते हैं:

• "नकली_सर्वर और दोस्तों को माइग्रेट करें" (90% हल हो गया है, बस थोड़ा सा बचा है - ऊपर देखें)।
• वेबसाइट प्रकाशित करें (देखें #1220: एक छोटी सी, अति-आसान चीज और एक मध्यम कार्य को पकड़ने के लिए)

मुझे लगता है कि ऊपर दिए गए अधिकांश अन्य अनक्लोज़ चेकमार्क पुराने IE रिलीज़ (6-10) से संबंधित हैं, जो मुझे पूरा यकीन है कि # 1221 में चर्चा के आधार पर समर्थित नहीं होंगे, इसलिए उन्हें अनदेखा किया जा सकता है। अब इसे संबोधित करेंगे।

@ sinonjs/sinon-core: पिछली टिप्पणी ने मुझे अवगत कराया कि हमारे ऊपर कुछ मुद्दे हैं जिन्हें हम # 1221 में चर्चा के आधार पर पूरा करने की संभावना नहीं रखते हैं:

1. लीगेसी IE समर्थन / समाधान निकालें?
2. फिक्सिंग xdomain

परवाह है कि क्या मैं विरासत आईई बिट्स को हटाने के लिए पीआर बनाता हूं अगर हम उन्हें किसी भी तरह स्पर्श नहीं करेंगे? मुझे लगता है कि xdomain ऐतिहासिक भूमि भरने में भी समाप्त हो सकता है, क्योंकि यह ज्यादातर आईई-केवल सीओआरएस-समान हैक था, इसलिए इसे हटाया जा सकता है?

@ fatso83 आह , के। मैं संदर्भित मुद्दों पर अद्यतन टिप्पणियों से चूक गया। मुझे आशा है कि मेरे लिए इसकी समीक्षा करना आपके लिए उपयोगी था!

असंबंधित: ऐसा लगता है कि इसका एक हिस्सा IE6 के लिए समर्थन छोड़ रहा है। बदकिस्मती से। आह ठीक है, सेस्ट ला मार्चे डू प्रोग्रेस! /=

हम मूल रूप से वहां हैं, डॉक्स साइट की अपनी समस्या है।

अरे चैप्स - कुछ भी हमें 2.0 को "स्थिर" सिनॉन रिलीज के रूप में चिह्नित करने और 1.x को मारने से रोक रहा है? :)

सोचें कि हम आखिरी चीज़ के रूप में #1297 चाहते थे।

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

तुम लोग सुंदर हो। <3