Sinon: fakeServer rusak dengan .respond (500) di 1.17.4

Saya dapat mengonfirmasi bahwa ini terjadi di 1.17.4 tetapi tidak di 1.17.3. Saya memiliki pengaturan serupa dengan karma-sinon.

Dugaan saya adalah masalahnya ada di komit ini https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

Tag 1.17.4 didorong ke registri npm tetapi saya tidak menemukan jejak apa pun dari tag ini di repositori ini. Apa yang terjadi?

Tebakan saya adalah tag tersebut belum dibuat. Itu baru dirilis 3 jam yang lalu

@mbarlock Ya, mungkin - meskipun demikian menurut saya akan lebih baik jika tag di GitHub dirilis lebih dulu. Setidaknya kami akan melihat dan membantu PR atau sesuatu untuk diperbaiki.

Salahku. Lupa git push --tags . Terima kasih atas info tentang bug tersebut.

Saya baru saja mengonfirmasi bahwa melakukan 2cfbacd pasti menyebabkan pengujian gagal untuk kita di mozilla / loop # 400.

Saya menerapkan tambalan dari # 1031 secara lokal, dan itu memperbaiki pengujian kami.

Jika 1.17.4 mengubah perilaku yang ada, bukankah seharusnya itu menjadi bagian dari rilis utama baru? Saat ini, dianggap kompatibel dengan 1.17.3, jadi package.json yang menetapkan dependensi sinon sebagai "^ 1.17.3" akan mendapatkan 1.17.4 dan berpotensi gagal dalam pengujian yang dulu berfungsi.

Cara kerja 1.17.3 adalah regresi, bukan? Jangan ragu untuk mengoreksi saya. Jika itu masalahnya, itu harus diperbaiki dan tidak dipertahankan dalam keadaan rusaknya.

PEMBARUAN: Ini terlihat seperti bug yang sebenarnya.

Oh, saya belum membaca diskusi asli Anda di https://github.com/sinonjs/sinon/pull/861 @fearphage . Sepertinya ini adalah perilaku yang benar, meskipun saya pikir itu akan berdampak lebih dari yang diharapkan, mengingat sudah berapa lama bug itu ada di basis kode Sinon.

Mengingat hal itu, sepertinya hal yang benar untuk saya lakukan adalah mengubah pengujian saya menjadi mengandalkan xhr.onabort daripada xhr.onerror. Saya menduga perubahan ini akan menyebabkan kebingungan untuk sementara waktu, karena pengujian unit yang dijalankan secara lokal tidak secara otomatis mengunduh ulang semua dependensi jika mereka ada di direktori node_modules, sehingga orang akan mengetahuinya ketika mereka menambahkan dependensi baru ke mereka. package.json (Saya menyadari dengan cepat karena Travis CI melakukan penginstalan npm dari awal untuk pengujian saya).

Saya tidak yakin apa tindakan yang benar. Mungkin menambahkan catatan ke changelog untuk 1.17.4 yang menetapkan bahwa beberapa pengujian yang mengandalkan "onerror" harus menggunakan "onabort"? (btw, pada komentar ini, http://sinonjs.org/Changelog.txt belum menyertakan 1.17.4).

Saya ambil kembali. Saya melihat untuk memperbaiki pengujian saya dan menyadari bahwa bug baru diperkenalkan di https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 . Fungsi onReadyStateChange sekarang memicu ProgressEvent "error" alih-alih mengandalkan fungsi abort untuk memanggil onerror secara langsung jika ditentukan. Masalahnya adalah bahwa FakeXMLHttpRequest saat ini tidak memiliki pendengar untuk peristiwa "kesalahan".

Saya telah membuat PR https://github.com/sinonjs/sinon/pull/1042 untuk menambahkan kunci eventListener kesalahan yang hilang. Tanpa perubahan ini, pengujian unit apa pun yang memeriksa fungsi penanganan kesalahan yang dipanggil pada respons kesalahan server yang sah (seperti 500) akan gagal. Beri tahu saya pendapat Anda, @fearphage @ fatso83

Pada pembacaan awal utas ini, saya tidak melihat https://github.com/sinonjs/sinon/pull/1041 , yang menambahkan kunci eventListener yang hilang dan kode tambahan untuk menegaskan urutan kejadian. Jangan ragu untuk mengabaikan PR saya jika Anda memilihnya.

Oke, # 1041 (sama seperti # 1042) sekarang telah digabungkan.

@overcaffeinated Mengenai

Hal-hal seperti ini membuat saya sangat ingin mengeluarkan 2.0 sehingga kami tidak menginvestasikan terlalu banyak energi di cabang 1.x.

1.7.4 menyebabkan beberapa pengujian saya gagal. Apakah kami mengharapkan 1.7.5 untuk menyelesaikan ini?

Sayangnya itu tidak akan memperbaikinya untuk semua orang, karena # 1031 belum diperbaiki. Saya akan mencoba dan membantu sepanjang malam ini.

Terima kasih atas infonya, @ Standard8 !

Saya memperbaiki (merusak?) Ini berdasarkan interpretasi saya tentang spesifikasi XHR. Alangkah baiknya jika ada implementasi browser untuk membandingkan ini untuk memastikannya kali ini benar. Kita memerlukan testbed untuk membandingkan implementasi xhr palsu sinon dengan kenyataan untuk memastikan peristiwa diaktifkan dalam urutan yang benar dan peristiwa yang benar diaktifkan.

Ada yang mau?

@fearphage tahu bagaimana testbed seperti itu akan terlihat? serangkaian tes manual? agak sulit untuk mensimulasikan "jaringan turun" di browser normal. jadi saya tidak begitu yakin bagaimana ini harus dilakukan.

Saya membayangkan itu akan seperti browsercope.org atau setidaknya bisa menggunakannya sebagai backend untuk menyimpan hasil.

Bayangkan http://www.acidtests.org/ untuk XHR

Berikut beberapa utilitas berbasis permintaan untuk membantu:

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

Sepertinya itu sumber daya yang luar biasa! Browserscope sedang down, btw.

@fearphage Saya tidak punya waktu untuk memikirkan cara memasukkan sesuatu ke

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

Memuat versi terbaru Firefox, Chrome, IE, dan Safari.

@ Standard8 Saya menghargainya. Saya telah menggunakan ini untuk membandingkan implementasi server palsu sinon. Terima kasih.

@fearphage @ fatso83 , dapatkah Anda memberikan gambaran umum tentang status terkini dari masalah ini?

Dari sekilas kedengarannya kita harus mempertimbangkan untuk mengembalikan fungsionalitas v1.17.3 dan menyediakan rilis v1.17.5 - meskipun fungsionalitas lama rusak, ini mewakili perubahan API yang melanggar dan oleh karena itu harus diluncurkan ke rilis 2.0?

Saya pikir Anda menyimpulkannya dengan baik, meskipun @fearphage lebih ke detail yang satu ini. Saya terus kewalahan dengan mencoba menahan di kepala saya apa yang ada di cabang v1.17 dan apa yang ada di master . Saya _think_ sebagian besar masalah telah diperbaiki di master , tetapi menurut saya itu tidak berlaku untuk cabang v1.17 (yang tidak memiliki perbaikan seperti # 1031 dan # 1041 AFAIK). Saya mungkin (mungkin) salah.

Saya pikir solusi paling pragmatis mungkin melakukan apa yang Anda katakan:

• kembalikan # 1017 (dan terkait?) untuk cabang 1,17 untuk menurunkan kebisingan dan menjaga API jaringan tetap sama, kirimkan rilis 1.17.5, dan terima saja bahwa penerapannya kurang benar daripada di versi 2
• simpan perubahan di master dan cukup dokumentasikan apa yang berubah dalam panduan migrasi (lihat # 1090).

Saya hanya mengejar apa yang terjadi di sini. Apakah lebih baik memperbaiki daripada mengembalikan?

Perubahan terbesar adalah ketika error / onerror dipecat atau tidak, bukan?

@fearphage Terima kasih telah

Meskipun perubahan besar tidak masalah untuk versi mayor yang baru, apa pun yang mulai merusak banyak pengujian di 1.x mungkin harus ditunda, tetapi saya tidak yakin apakah perbaikan tersebut telah diterapkan ke master akan menyelesaikan masalah _most_ yang dialami orang dengan 1.17.4.

Sejauh yang saya pahami, satu-satunya hal yang rusak adalah permintaan non-200 masih harus memicu peristiwa error . Apakah ada lebih dari ini? Saya percaya semua yang dibutuhkan adalah perbaikan dari master.

Sepertinya ide yang bagus untuk menarik v1.7.4 dari Github dan NPM juga. Kebanyakan orang mengembalikannya atau tidak dapat meningkatkannya.

Jika hanya itu yang berubah, saya sarankan untuk menyertakan perbaikan yang telah berubah menjadi master dan mengirimkan rilis 1.17.5 secepatnya. Bisakah kamu melakukannya? Saya akan pergi berlibur ( Date.now() ).

Karena menghapus versi NPM tidak dianggap "bagus", saya mengeluarkan perintah npm deprecate untuk 1.17.4. Tidak yakin tentang menghapus tag juga, jika beberapa orang mengandalkannya. Itu diskusi lain, dan saya sarankan kita fokus pada pengiriman perbaikan.

Kedengaranya seperti sebuah rencana. Saya harus bisa melakukannya akhir pekan ini.

Saya memiliki usulan perbaikan untuk masalah ini jika ada yang ingin mempertimbangkan # 1102.

Jika ada yang membutuhkannya, saya memodifikasi sedikit file pengujian @ Standard8 dan inilah yang telah saya gunakan untuk membuat xhr palsu lebih dekat dengan perilaku browser.

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

@ Standard8 Terima kasih lagi! :tepuk:

Menurut peristiwa kesalahan spesifikasi dipicu hanya ketika peristiwa tingkat jaringan seperti waktu tunggu DNS atau server tidak responsif terjadi. 500 atau 404 hanyalah respons HTTP biasa dan terserah aplikasi untuk memutuskan apakah kesalahan telah terjadi. https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
Speknya terlalu ringkas seperti biasanya. Respons non 2xx dianggap error oleh jQuery, itulah sebabnya banyak orang bingung dengan perilaku XMLHttpRequest.

@ nyk0r : cukup banyak yang dilakukan perbaikan Phred :)

@gil : ini harus diperbaiki oleh karya @fearphage yang sangat baik di # 1102, # 1108 dan # 1109. Karena kasus pengujian Anda tidak lengkap (tidak ada pemeriksaan / verifikasi), maukah Anda memverifikasi bahwa kasus tersebut memang telah diperbaiki oleh kode di cabang v1.17 saat ini? Jika Anda melakukannya, kami dapat mengirimkan rilis patch baru SECEPATNYA.

Atau, @wlepinski atau @mbarlock mungkin dapat memverifikasi bahwa ini telah diperbaiki di cabang v1.17 ? Ubah saja ketergantungan sinon di package.json menjadi: sinon#v1.17 untuk menggunakan cabang kanan langsung dari GitHub.

Oke, diverifikasi untuk diperbaiki dengan menjalankan tes ini:

"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);
}

Ini tidak berfungsi dengan 1.17.4, tetapi berfungsi dengan perbaikan terbaru.

Ternyata @fearphage sudah membahas tes ini di bf709a7f (baris 1797), tapi hei ...

Menutup sebagai sudah diperbaiki.

Sayangnya saya tidak memiliki akses ke proyek itu untuk mengujinya lagi, saya bekerja di perusahaan baru sekarang. Tapi saya akan memberi tahu mereka, jika mereka ingin memperbarui perpustakaan. Terima kasih atas perbaikannya !!