Sinon: नकली सर्वर 1.17.4 पर .response (500) के साथ टूट गया है

मैं पुष्टि कर सकता हूं कि यह 1.17.4 पर होता है लेकिन 1.17.3 को नहीं। मेरे पास कर्म-सिनॉन के साथ एक समान सेटअप है।

मेरा अनुमान है कि समस्या इस प्रतिबद्धता में है https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

टैग 1.17.4 को npm रजिस्ट्री में धकेल दिया गया था लेकिन मुझे इस रिपॉजिटरी पर इस टैग का कोई निशान नहीं मिला। क्या हुआ?

मेरा अनुमान है कि टैग अभी बनाया नहीं गया है। इसे केवल 3 घंटे पहले जारी किया गया था

@mbarlock हाँ, शायद - फिर भी मुझे लगता है कि बेहतर होगा यदि GitHub पर टैग पहले जारी किया गया हो। कम से कम हम एक पीआर या कुछ ठीक करने के लिए एक नज़र डालेंगे और मदद करेंगे।

मेरा बुरा। git push --tags भूल गए। बग के बारे में जानकारी के लिए धन्यवाद।

मैंने अभी पुष्टि की है कि 2cfbacd निश्चित रूप से हमारे लिए मोज़िला/लूप # 400 में परीक्षण विफल हो गया है।

मैंने स्थानीय स्तर पर #1031 से पैच लागू किया, और यह हमारे परीक्षणों को ठीक करता है।

यदि 1.17.4 मौजूदा व्यवहार को बदलता है, तो क्या यह एक नई प्रमुख रिलीज़ का हिस्सा नहीं होना चाहिए? वर्तमान में, इसे 1.17.3 के साथ संगत माना जाता है, इसलिए एक package.json एक sinon निर्भरता को "^1.17.3" के रूप में निर्दिष्ट करते हुए 1.17.4 प्राप्त करेगा और संभावित रूप से विफल परीक्षण जो काम करते थे।

जिस तरह से 1.17.3 काम करता है वह एक प्रतिगमन है, है ना? मुझे सही करने के लिए स्वतंत्र महसूस करें। यदि ऐसा है, तो इसे ठीक किया जाना चाहिए और इसकी टूटी हुई अवस्था में नहीं रखा जाना चाहिए।

अद्यतन: यह एक वास्तविक बग की तरह दिखता है।

ओह, मैंने आपकी मूल चर्चा https://github.com/sinonjs/sinon/pull/861 @fearphage पर नहीं पढ़ी थी। ऐसा लगता है कि यह सही व्यवहार है, हालांकि मुझे लगता है कि इसका इरादा से अधिक प्रभाव पड़ेगा, यह देखते हुए कि सिनॉन कोडबेस में बग कितने समय से है।

यह देखते हुए, ऐसा लगता है कि मेरे अंत में करने के लिए सही काम xhr.onerror के बजाय xhr.onabort पर भरोसा करने के लिए मेरे परीक्षणों को बदलना है। मुझे संदेह है कि यह परिवर्तन थोड़ी देर के लिए भ्रम पैदा करेगा, क्योंकि स्थानीय रूप से चलने वाले यूनिट परीक्षण स्वचालित रूप से सभी निर्भरताओं को फिर से डाउनलोड नहीं करते हैं यदि वे नोड_मॉड्यूल निर्देशिका में मौजूद हैं, इसलिए लोग इस बारे में पता लगाएंगे जब वे नई निर्भरता जोड़ते हैं उनके package.json (मुझे जल्दी एहसास हुआ क्योंकि ट्रैविस सीआई मेरे परीक्षणों के लिए स्क्रैच से एनपीएम इंस्टॉल करता है)।

मुझे यकीन नहीं है कि कार्रवाई का सही तरीका क्या है। हो सकता है कि 1.17.4 के लिए चेंजलॉग में एक नोट जोड़ें जिसमें यह निर्दिष्ट किया गया हो कि कुछ परीक्षण जो "आतंक" पर निर्भर हैं, उन्हें "ऑनबॉर्ट" का उपयोग करना चाहिए? (बीटीडब्ल्यू, इस टिप्पणी के अनुसार, http://sinonjs.org/Changelog.txt में अभी तक 1.17.4 शामिल नहीं है)।

मैं उसे वापस ले लेता हूँ। मैंने अपने परीक्षणों को ठीक करने पर ध्यान दिया और महसूस किया कि https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 में एक नया बग पेश किया गया था। onReadyStateChange फ़ंक्शन अब परिभाषित होने पर सीधे आतंक को कॉल करने के लिए निरस्त फ़ंक्शन पर निर्भर होने के बजाय एक "त्रुटि" प्रोग्रेसइवेंट को ट्रिगर करता है। समस्या यह है कि FakeXMLHttpRequest में वर्तमान में "त्रुटि" घटना के लिए श्रोता नहीं है।

मैंने पीआर बनाया है https://github.com/sinonjs/sinon/pull/1042 लापता त्रुटि ईवेंट लिस्टनर कुंजी जोड़ने के लिए। इस परिवर्तन के बिना, कोई भी इकाई परीक्षण जो एक वैध सर्वर त्रुटि प्रतिक्रिया (जैसे 500) पर कॉल किए जा रहे एक आतंक हैंडलर फ़ंक्शन की जांच करता है, विफल हो जाएगा। मुझे अपने विचार बताएं , @fatso83

इस धागे के अपने प्रारंभिक पढ़ने पर मैंने https://github.com/sinonjs/sinon/pull/1041 नहीं देखा, जो घटनाओं के क्रम पर जोर देने के लिए लापता ईवेंट लिस्टनर कुंजी और अतिरिक्त कोड जोड़ता है। मेरे पीआर की अवहेलना करने के लिए स्वतंत्र महसूस करें यदि आप इसके बजाय इसके साथ जाते हैं।

ठीक है, #1041 (#1042 के समान) अब इसमें विलय कर दिया गया है।

@overcaffeinated लापता चैंज के बारे में जो डॉक्स के लिए बिल्ड स्क्रिप्ट में विफलता के कारण है जो मुझे उन्हें अपडेट करने से रोकता है (देखें https://github.com/sinonjs/sinon/issues/991#issuecomment-216651347)। उसके लिए माफ़ करना। उम्मीद है कि हम इसे फिर से काम कर सकते हैं और वहां बदलाव पर एक नोट जोड़ सकते हैं।

इस तरह की चीजें मुझे वास्तव में 2.0 को दरवाजे से बाहर निकालना चाहती हैं ताकि हम 1.x शाखा में बहुत अधिक ऊर्जा का निवेश न करें।

1.7.4 के कारण मेरे कई परीक्षण विफल हो गए। क्या हम 1.7.5 से इसका समाधान करने की अपेक्षा करते हैं?

दुर्भाग्य से यह इसे सभी के लिए ठीक नहीं करेगा, क्योंकि #1031 अभी तक तय नहीं हुआ है। मैं कोशिश करूँगा और इस शाम के साथ मदद करूँगा।

जानकारी के लिए धन्यवाद, @ Standard8 !

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

कोई लेने वाला?

@fearphage कोई विचार है कि ऐसा टेस्टबेड कैसा दिखता है? मैनुअल परीक्षणों का एक सूट? सामान्य ब्राउज़र में "नेटवर्क डाउन" का अनुकरण करना कठिन है। तो मुझे सच में यकीन नहीं है कि यह कैसे किया जाना चाहिए।

मुझे लगता है कि यह browserscope.org जैसा होगा या कम से कम यह परिणामों को स्टोर करने के लिए बैकएंड के रूप में उपयोग कर सकता है।

हालांकि XHR के लिए http://www.acidtests.org/ की कल्पना

सहायता के लिए यहां कुछ अनुरोध-आधारित उपयोगिताएं दी गई हैं:

https://httpbin.org/
http://requestb.in/

यह उत्कृष्ट संसाधनों की तरह लगता है! ब्राउजरस्कोप नीचे है, बीटीडब्ल्यू।

@fearphage मेरे पास www.browserscope.org में कुछ प्राप्त करने का तरीका जानने का समय नहीं था, इसलिए मैंने इसके बजाय एक वेब पेज को व्हिप किया:

http://people.mozilla.org/~mbanner2/sinonXHRBrowserTest.html

फ़ायरफ़ॉक्स, क्रोम, आईई और सफारी के नवीनतम संस्करणों में लोड।

@ मानक 8 मैं इसकी सराहना करता हूं। मैं इसका उपयोग सिनॉन के नकली सर्वर कार्यान्वयन की तुलना करने के लिए कर रहा हूं। धन्यवाद।

@ fearphage @fatso83 , क्या आप कृपया इस मुद्दे की वर्तमान स्थिति का एक सिंहावलोकन प्रदान कर सकते हैं?

इसके माध्यम से एक त्वरित स्किम से ऐसा लगता है कि हमें v1.17.3 कार्यक्षमता को वापस लाने और v1.17.5 रिलीज़ प्रदान करने पर विचार करना चाहिए - भले ही पुरानी कार्यक्षमता टूट गई हो, यह एक ब्रेकिंग एपीआई परिवर्तन का प्रतिनिधित्व करता है और इसलिए इसे 2.0 रिलीज़ में रोल किया जाना चाहिए?

मुझे लगता है कि आपने इसे अच्छी तरह से सारांशित किया है, हालांकि master में क्या है, इसे अपने दिमाग में रखने की कोशिश करके मैं अभिभूत हो जाता हूं। मैं _थिंक_ अधिकांश समस्याओं को master में ठीक कर दिया गया है, लेकिन मुझे नहीं लगता कि यह v1.17 शाखा के लिए है (जिसमें #1031 और #1041 AFAIK जैसे सुधार नहीं हैं)। मैं (शायद हूँ) गलत हो सकता हूँ।

मुझे लगता है कि सबसे व्यावहारिक समाधान हो सकता है जैसा आपने कहा था:

• 1.17 शाखा के शोर को कम करने और नेटवर्क एपीआई को समान रखने के लिए #1017 (और संबंधित?) को वापस लाएं, 1.17.5 रिलीज को शिप करें, और केवल यह स्वीकार करें कि कार्यान्वयन संस्करण 2 की तुलना में कम सही है
• परिवर्तनों को master और माइग्रेशन मार्गदर्शिका में जो कुछ बदला है उसे केवल दस्तावेज़ करें (#1090 देखें)।

मैं अभी समझ रहा हूं कि यहां क्या हो रहा है। क्या इसे वापस करने से ठीक करना बेहतर होगा?

सबसे बड़ा परिवर्तन तब होता है जब error / onerror निकाल दिया जाता है या नहीं, है ना?

@fearphage इसमें शामिल होने के लिए धन्यवाद! चूंकि मैं अपेक्षाकृत धीमा हूं, क्या आप कृपया पांच पंक्तियों का सारांश बना सकते हैं कि मौजूदा अंतिम उपयोगकर्ता के दृष्टिकोण से कौन से एपीआई परिवर्तन स्पष्ट होंगे जब सभी सुधार v1.17 शाखा पर लागू किए गए हैं?

जबकि एक नए प्रमुख संस्करण के लिए बड़े बदलाव ठीक होंगे, कुछ भी जो 1.x में बहुत सारे परीक्षणों को तोड़ना शुरू कर देता है, शायद होल्ड पर होना चाहिए, लेकिन मुझे यकीन नहीं था कि उन सुधारों को master लागू किया गया है या नहीं

जहां तक ​​​​मैं इसे समझता हूं, केवल एक चीज टूटा हुआ है गैर -200 अनुरोध अभी भी error घटनाओं को ट्रिगर करना चाहिए। क्या इसमें और भी कुछ है? मेरा मानना ​​है कि इसके लिए केवल मास्टर की ओर से सुधार की आवश्यकता है।

ऐसा लगता है कि v1.7.4 को Github और NPM से भी निकालना एक अच्छा विचार है। अधिकांश लोग इसे पूर्ववत कर रहे हैं या इसमें अपग्रेड नहीं कर सकते हैं।

अगर यह सब बदल गया है तो मैं सुझाव दूंगा कि इसमें master में गए सुधारों को शामिल किया जाए और 1.17.5 रिलीज ASAP को शिप किया जाए। क्या आप यह कर सकते है? मैं छुट्टी मनाने जा रहा हूँ ( Date.now() )।

चूंकि एनपीएम संस्करणों को हटाना बहुत "अच्छा" नहीं माना जाता है, npm deprecate मैंने 1.17.4 के लिए

एक योजना की तरह लगता है। मुझे इस सप्ताह के अंत में इसे प्राप्त करने में सक्षम होना चाहिए।

मेरे पास इस मुद्दे का एक प्रस्तावित समाधान है यदि कोई #102 पर वजन करना चाहता है।

अगर किसी को इसकी आवश्यकता है, तो मैंने @ Standard8 की परीक्षण फ़ाइल को थोड़ा संशोधित किया है और यही वह है जिसका उपयोग मैं नकली xhr को ब्राउज़र व्यवहार के करीब लाने के लिए कर रहा हूं।

https://dl.dropboxusercontent.com/u/2400/tc/sinon/xhr-browser-test.htm

@ मानक 8 फिर से धन्यवाद! :ताली:

युक्ति के अनुसार आतंक घटना तभी ट्रिगर होती है जब एक नेटवर्क स्तर की घटना जैसे DNS टाइमआउट या उत्तरदायी सर्वर नहीं होता है। 500 या 404 केवल सामान्य HTTP प्रतिक्रियाएं हैं और यह तय करने के लिए एक एप्लिकेशन पर निर्भर है कि कोई त्रुटि हुई है या नहीं। https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
युक्ति हमेशा की तरह बहुत संक्षिप्त है. गैर 2xx प्रतिक्रियाओं को jQuery द्वारा त्रुटियां माना जाता है, इसलिए बहुत से लोग XMLHttpRequest के व्यवहार से भ्रमित होते हैं।

@ nyk0r : यह बहुत ज्यादा है जो फ्रेड का फिक्स करता है :)

@gil : इसे @fearphage के उत्कृष्ट कार्य द्वारा #११०२, #११०८ और #११०९ में ठीक किया जाना चाहिए। चूंकि आपका परीक्षण मामला अधूरा है (कोई जांच/सत्यापन नहीं), क्या आप यह सत्यापित करना चाहेंगे कि यह वास्तव में वर्तमान v1.17 शाखा में कोड द्वारा तय किया गया है? यदि आप ऐसा करते हैं, तो हम जल्द से जल्द एक नया पैच रिलीज़ शिप कर सकते हैं।

वैकल्पिक रूप से, @wlepinski या @mbarlock शायद यह सत्यापित कर सकता है कि यह v1.17 शाखा में तय किया गया है? package.json में पढ़ने के लिए बस sinon निर्भरता को बदलें: sinon#v1.17 सीधे GitHub से सही शाखा का उपयोग करने के लिए।

ठीक है, इस परीक्षण को चलाकर ठीक किए जाने की पुष्टि की गई है:

"call load handler on non-2xx statuses" : function(){
  var stub = sinon.stub();
  this.xhr.addEventListener("load", stub);
  this.xhr.open("GET", "/");
  this.xhr.send();

  this.xhr.respond(500, { 'Content-Type' : 'application/json' }, JSON.stringify({}));
  assert(stub.called);
}

यह 1.17.4 के साथ काम नहीं करता था, लेकिन नवीनतम सुधारों के साथ करता है।

पता चला @fearphage ने पहले ही इस परीक्षण को bf709a7f (लाइन 1797) में कवर कर लिया है, लेकिन हे ...

तय के रूप में बंद।

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