Sinon: تم كسر خادم fakeServer بـ .Respond (500) في 1.17.4

يمكنني أن أؤكد أن هذا يحدث في 1.17.4 ولكن ليس 1.17.3. لدي إعداد مماثل مع karma-sinon.

تخميني أن المشكلة تكمن في هذا الالتزام https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

تم دفع العلامة 1.17.4 إلى سجل npm لكنني لم أجد أي أثر لهذه العلامة في هذا المستودع. ماذا حدث؟

تخميني هو أن العلامة لم يتم إنشاؤها بعد. تم إصداره منذ 3 ساعات فقط

mbarlock نعم ، على الأرجح - مع ذلك أعتقد أنه سيكون من الأفضل إذا تم إصدار العلامة على GitHub أولاً. على الأقل سنلقي نظرة ونساعد في العلاقات العامة أو أي شيء لإصلاحه.

خطأي. نسيت git push --tags . شكرا للمعلومات عن الخطأ.

لقد أكدت للتو أن الالتزام 2cfbacd تسبب بالتأكيد في فشل الاختبارات بالنسبة لنا في mozilla / loop # 400.

قمت بتطبيق التصحيح من # 1031 محليًا ، وقام بإصلاح اختباراتنا.

إذا غيّر 1.17.4 السلوك الحالي ، ألا يجب أن يكون جزءًا من إصدار رئيسي جديد؟ حاليًا ، يعتبر متوافقًا مع 1.17.3 ، لذا فإن الحزمة التي تحدد تبعية sinon كـ "^ 1.17.3" ستحصل على 1.17.4 وربما تفشل في الاختبارات التي كانت تعمل.

الطريقة التي يعمل بها 1.17.3 هي تراجع ، أليس كذلك؟ لا تتردد في تصحيح لي. إذا كان الأمر كذلك ، فيجب إصلاحه وعدم صيانته في حالته المعطلة.

تحديث: هذا يبدو وكأنه خطأ حقيقي.

أوه ، لم أقرأ مناقشتك الأصلية على https://github.com/sinonjs/sinon/pull/861fearphage . يبدو أن هذا هو السلوك الصحيح ، على الرغم من أنني أعتقد أنه سيكون له تأثير أكبر مما هو مقصود ، بالنظر إلى المدة التي قضاها الخطأ في قاعدة بيانات Sinon لمدة.

بالنظر إلى ذلك ، يبدو أن الشيء الصحيح الذي يجب القيام به من جهتي هو تغيير اختباراتي للاعتماد على xhr.onabort بدلاً من xhr.onerror. أظن أن هذا التغيير سيسبب ارتباكًا لبعض الوقت ، نظرًا لأن اختبارات الوحدة التي يتم تشغيلها محليًا لا تعيد تنزيل جميع التبعيات تلقائيًا إذا كانت موجودة في دليل node_modules ، لذلك سيتعرف الأشخاص على هذا الأمر عندما يضيفون تبعيات جديدة إلى package.json (أدركت سريعًا لأن Travis CI يقوم بتثبيت npm من البداية لاختباراتي).

لست متأكدًا من المسار الصحيح للعمل. ربما تضيف ملاحظة إلى سجل التغيير لـ 1.17.4 تحدد أن بعض الاختبارات التي تعتمد على "عند الخطأ" يجب أن تستخدم "onabort"؟ (راجع للشغل ، اعتبارًا من هذا التعليق ، لا يتضمن http://sinonjs.org/Changelog.txt 1.17.4 حتى الآن).

أستعيد ذلك. نظرت في إصلاح اختباراتي وأدركت أنه تم إدخال خطأ جديد في https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 . تعمل وظيفة onReadyStateChange الآن على تشغيل ProgressEvent "خطأ" بدلاً من الاعتماد على وظيفة الإحباط للاتصال بالخطأ مباشرةً إذا تم تعريفه. المشكلة هي أن FakeXMLHttpRequest حاليًا لا يحتوي على مستمع لحدث "الخطأ".

لقد قمت بإنشاء العلاقات العامة https://github.com/sinonjs/sinon/pull/1042 لإضافة مفتاح eventListener الخاص بالخطأ المفقود. بدون هذا التغيير ، ستفشل أي اختبارات وحدة تتحقق من استدعاء دالة معالج عند حدوث خطأ عند استجابة شرعية لخطأ الخادم (مثل 500). اسمحوا لي أن أعرف أفكاركم ، fearphage @ fatso83

في قراءتي الأولية لهذا الموضوع ، لم أرَ https://github.com/sinonjs/sinon/pull/1041 ، والذي يضيف مفتاح EventListener المفقود وكودًا إضافيًا لتأكيد ترتيب الأحداث. لا تتردد في تجاهل العلاقات العامة الخاصة بي إذا ذهبت مع ذلك بدلاً من ذلك.

حسنًا ، تم دمج # 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. سيكون من الجيد إذا كان هناك تطبيق متصفح لمقارنة ذلك للتأكد من صحته هذه المرة. نحتاج إلى اختبار لمقارنة تنفيذ xhr المزيف لـ sinon بالواقع للتأكد من أن الأحداث يتم إطلاقها بالترتيب الصحيح وإطلاق الأحداث الصحيحة.

أي من الأشخاص يود ذلك؟

fearphage أي فكرة كيف الاختبار ؟ مجموعة من الاختبارات اليدوية؟ نوع من الصعب محاكاة "تعطل الشبكة" في المتصفحات العادية. لذلك لست متأكدًا حقًا من كيفية القيام بذلك.

أتخيل أنه سيكون مثل المستعرضات المتصفحات أو على الأقل يمكنه استخدام ذلك كواجهة خلفية لتخزين النتائج.

تخيل http://www.acidtests.org/ لـ XHR بالرغم من ذلك

فيما يلي بعض الأدوات المساعدة القائمة على الطلب للمساعدة:

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

هذا يبدو وكأنه موارد ممتازة! Browserscope معطل ، راجع للشغل.

fearphage لم يكن لدي وقت للعمل على كيفية الحصول على شيء ما في www.browserscope.org ، لذلك قمت بجلد صفحة ويب بدلاً من ذلك:

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

يتم تحميله بأحدث إصدارات Firefox و Chrome و IE و Safari.

@ Standard8 أقدر ذلك. لقد كنت أستخدم هذا لمقارنة تطبيق خادم sinon المزيف. شكرا لك.

fearphage @ fatso83 ، هل يمكنك من فضلك تقديم لمحة عامة عن الوضع الحالي لهذه المشكلة؟

من خلال قراءة سريعة من خلالها ، يبدو أننا يجب أن نفكر في إعادة وظيفة v1.17.3 وتوفير إصدار v1.17.5 - حتى مع تعطل الوظيفة القديمة ، فإن هذا يمثل تغييرًا في واجهة برمجة التطبيقات وبالتالي يجب إدخاله في الإصدار 2.0؟

أعتقد أنك لخصتها بشكل جيد ، على الرغم من أن master . أعتقد أن معظم المشكلات تم إصلاحها في master ، لكنني لا أعتقد أن هذا ينطبق على فرع v1.17 (الذي لا يحتوي على إصلاحات مثل # 1031 و # 1041 AFAIK). قد أكون مخطئا (ربما أكون).

أعتقد أن الحل الأكثر واقعية هو أن تفعل ما قلته:

• قم بالعودة إلى رقم 1017 (وما يتصل به؟) لفرع 1.17 لتقليل الضوضاء والحفاظ على واجهة برمجة تطبيقات الشبكة كما هي ، وشحن إصدار 1.17.5 ، واقبل فقط أن التنفيذ أقل صحة مما كان عليه في الإصدار 2
• احتفظ بالتغييرات في master وقم فقط بتوثيق ما تم تغييره في دليل الترحيل (راجع # 1090).

أنا فقط ألحق بما يجري هنا. هل سيكون الإصلاح أفضل من العودة؟

التغيير الأكبر هو عندما يتم تشغيل error / onerror أم لا ، أليس كذلك؟

fearphage شكرا على

في حين أن التغييرات الكبيرة ستكون مناسبة لإصدار رئيسي جديد ، فمن المحتمل أن يكون أي شيء يبدأ في كسر الكثير من الاختبارات في 1.x معلقًا ، لكنني لم أكن متأكدًا مما إذا كانت تلك الإصلاحات التي تم تطبيقها على master سوف يحل _ Most_ القضايا التي يواجهها الناس مع 1.17.4.

بقدر ما أفهمه ، الشيء الوحيد الذي تم كسره هو أن الطلبات غير 200 يجب أن تستمر في تشغيل أحداث error . هل هناك المزيد لهذا؟ أعتقد أن كل ما تحتاجه هو الإصلاحات من السيد.

يبدو أنها فكرة جيدة أن تقوم بسحب v1.7.4 من Github و NPM أيضًا. يقوم معظم الأشخاص بإعادته أو لا يمكنهم الترقية إليه.

إذا كان هذا هو كل ما تغير ، فإنني أقترح فقط تضمين الإصلاحات التي دخلت إلى master وشحن إصدار 1.17.5 في أسرع وقت ممكن. هل يمكن أن تفعل ذلك؟ سأسافر بعيدًا لقضاء عطلة ( Date.now() ).

نظرًا لأن إزالة إصدارات NPM لا تعتبر "لطيفة" جدًا ، فقد أصدرت أمر npm deprecate مقابل 1.17.4. لست متأكدًا من إزالة العلامة أيضًا ، إذا كان بعض الأشخاص يعتمدون عليها. هذه مناقشة أخرى ، وأقترح أن نركز على شحن الإصلاح.

تبدو كخطة. يجب أن أكون قادرًا على الوصول إليه في نهاية هذا الأسبوع.

لديّ إصلاح مقترح لهذه المشكلة إذا أراد أي شخص التفكير في # 1102.

إذا احتاج أي شخص إليه ، فقد قمت بتعديل ملف اختبار @ Standard8 قليلاً وهذا ما كنت أستخدمه لتقريب xhr المزيف من سلوك المتصفح.

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

@ Standard8 شكرا مرة أخرى! : تصفيق:

وفقًا للمواصفات ، لا يتم تشغيل حدث الخطأ إلا عند حدوث حدث على مستوى الشبكة مثل انتهاء مهلة DNS أو عدم استجابة الخادم. 500 أو 404 هي مجرد استجابات HTTP عادية والأمر متروك للتطبيق لتقرير ما إذا كان قد حدث خطأ أم لا. https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
المواصفات موجزة للغاية كالمعتاد. تعتبر الاستجابات بخلاف 2xx أخطاءً بواسطة jQuery ، ولهذا السبب يختلط سلوك XMLHttpRequest على العديد من الأشخاص.

@ nyk0r : هذا ما يفعله إصلاح

gil : يجب إصلاح هذا من خلال عمل fearphage الممتاز في # 1102 و # 1108 و # 1109. نظرًا لأن حالة الاختبار الخاصة بك غير مكتملة (لا يوجد فحص / تحقق) ، فهل تهتم بالتحقق من أنه تم بالفعل إصلاحه بواسطة الرمز في الفرع الحالي الإصدار 1.17؟ إذا قمت بذلك ، فيمكننا شحن إصدار تصحيح جديد في أسرع وقت ممكن.

بدلا من ذلك،wlepinski أو ربما يمكنmbarlock تحقق من أن هذا قد تم إصلاحها في v1.17 الفرع؟ ما عليك سوى تغيير تبعية sinon في package.json لقراءة: 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) ، ولكن مهلا ...

إغلاق كما تم إصلاحه.

لسوء الحظ ، لا يمكنني الوصول إلى هذا المشروع لاختباره بعد الآن ، فأنا أعمل في شركة جديدة الآن. لكنني سأخبرهم ، في حالة رغبتهم في تحديث المكتبة. شكرا على الإصلاح !!