Sinon: Jika tidak 2.0 Rilis

Saya ingin membuat situs web dokumentasi baru, berdasarkan karya yang sudah ada di /docs . Saya berharap untuk menghabiskan beberapa jam untuk itu selama liburan saya minggu depan.

@mroderick Jika Anda memiliki pekerjaan yang didorong ke suatu tempat, beri tahu saya. Saya mungkin bisa membantu dengan dokumen!

Memperbarui kotak centang. Tidak yakin apakah "Migrate sinon.sandbox" harus dicentang, tetapi setidaknya PR ditutup.

@jonnyreeves : tidak yakin mengapa kita harus menghapus sinon.test . Ini adalah kotak pasir di sekitar pengujian yang membersihkan stub yang dibuat dan memata-matai secara otomatis setelah pengujian. Itu meringankan orang dari banyak fungsi beforeEach dan afterEach . Sangat berguna, dan tidak ada hubungannya dengan kerangka pengujian.

Pengguna perlu melihat alternatif yang mudah untuk ini agar ini dihapus demi sesuatu yang lain (lebih baik).

Saya sendiri tidak pernah menggunakan sinon.testCase , mungkin karena apinya cocok dengan BusterJS (di mana setiap test case adalah properti dari test suite) dan bukan Mocha (di mana setiap test adalah fungsi anonim yang berjalan di badan test suite ).

@fatso83 Masalah utama yang saya miliki dengan sinon.test adalah fakta bahwa ia bergantung pada singleton sinon.config . Pengguna IMHO dapat memiliki kontrol yang jauh lebih besar dengan membuat (dan memulihkan) kotak pasir di kait beofreEach dan afterEach kerangka uji mereka.

Jika kita akan menyimpan sinon.test (dan sinon.testCase ) di API publik; maka kita perlu mengatasi kedua masalah ini - meskipun pengguna lama / dukungan sinon, saya baru meretas proyeknya - bagaimana kita harus mencapai konsensus?

@jonnyreeves OK, lebih masuk akal ketika Anda menyebutkan itu mengandalkan sinon.config . IMHO secara eksplisit membuat dan memulihkan kotak pasir baik-baik saja selama kami menyediakan ini sebagai alternatif untuk orang-orang yang berasal dari Sinon 1 dan bertanya-tanya apa yang pernah terjadi pada sinon.test . Jadi dokumentasinya harus membaca sesuatu seperti

sinon.test

_Ini telah ditinggalkan di versi 2 demi membuat kotak pasir secara eksplisit. Lihat link to sandbox ._

Saya setuju dengan API yang lebih ramping di versi 2, jadi hal-hal seperti typeOf , extends dan sinon.test* dapat dilayani dengan lebih baik oleh modul NPM lain atau fungsi lain yang ada.

Saya pikir sesuatu seperti npm install sinon-test dan var sinonTest = require('sinon-test')(config); bisa menjadi pengganti yang layak.

:+1: untuk memindahkan utilitas seperti ini ke modul npm terpisah. Lebih sedikit kode di core

Terima kasih atas masukannya; Saya telah memperbarui ikhtisar di bagian atas untuk mencerminkan diskusi sejauh ini (terutama menghilangkan tanda tanya, membuat tugas lebih jelas), silakan lihat.

Juga, bisakah kita mendapatkan penutupan serupa pada:

• menghapus sinon.log dan sinon.logError (keduanya digunakan oleh fake_server; dan mungkin akan lebih baik diteruskan sebagai konfigurasi ke instance tersebut)
• menghapus sinon.mock dari 2.0

Terima kasih

Saya tidak pernah menggunakan sinon.testCase , namun saya pengguna berat sinon.test . Saya baik-baik saja dengan masuk ke perpustakaan terpisah, tetapi hanya untuk tidak lupa: ada beberapa orang yang menggunakan kerangka uji yang tidak mendukung beforeEach berdasarkan desain (mis. pita) dengan argumen bahwa pengaturan ini fungsi mengarah ke kasus uji digabungkan. Kami mungkin menyebabkan banyak masalah bagi pengguna ini jika tidak ada penggantian drop-in yang sederhana.

Saya kira kami dapat menawarkan sesuatu seperti ini sebagai jalur migrasi:

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

@mantoni : Saran yang bagus. Dengan hanya menetapkan ke properti test sekarang tidak digunakan, ini memberi orang sedikit kerumitan hanya dengan memasukkan satu baris tambahan dalam pengujian mereka. Kita hanya perlu memastikan bahwa objek sinon tidak dibekukan (seperti pada Object.freeze(sinon) ) di beberapa titik ...

@jonnyreeves : mengenai sinon.mock Saya ingat @mroderick menyarankan untuk menunggu hingga 2.0 dirilis sebelum menghapus ini. Kami telah memberi isyarat untuk beberapa waktu bahwa itu sudah usang, jadi tidak apa-apa untuk menghapusnya setelah rilis 2.0 IMHO. Tetapi karena kami sudah memiliki dukungan CommonJS, saya tidak keberatan menghapusnya sebelum rilis 2.0 _if_ kami telah mengekstrak kode ke dalam modulnya sendiri. Kemudian orang hanya bisa let sinon.mock = require('sinon-mock') , jika mereka mau.

Mengenai sinon.log* , saya tidak melihat alasan untuk mempertahankannya sebagai fitur publik jika kami dapat menyediakannya sebagai konfigurasi saat diperlukan.

WRT memfaktorkan sinon-test , perhatikan saja bahwa kita perlu mengizinkan konsumen untuk menyediakan konfigurasi, yaitu:

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

atau serupa.

Baru saja melihat kemungkinan perubahan API lainnya saat membuat paket sinon-test ; ada pemikiran tentang apa yang harus terjadi pada sinon.assert ? Sekali lagi ini tidak terasa seperti bagian inti dari sinon API bagi saya dan mungkin lebih cocok dengan bermigrasi ke paket sinon-test bersama sinon.test dan sinon.testCase ?

@fatso83 @mantoni @cjohansen; Saya memiliki paket sinon-test yang siap untuk ditinjau - dapatkah salah satu dari Anda menginisialisasi git repo kosong di sinonjs/sinon-test sehingga saya dapat mengajukan PR terhadapnya?

Terima kasih

Itu tadi cepat! https://github.com/sinonjs/sinon-test

@cjohansen bisakah Anda mendorong README kosong ke sana? Sepertinya saya tidak bisa menaikkan PR dalam kondisi saat ini.

Selesai

Terima kasih, PR diangkat - umpan balik diterima: https://github.com/sinonjs/sinon-test/pull/1

@mroderick Jika Anda memiliki pekerjaan yang didorong ke suatu tempat, beri tahu saya. Saya mungkin bisa membantu dengan dokumen!

@spinningarrow itu bagus. Saya telah membuat #991 untuk melacak ini secara terpisah dari upaya lainnya. Saya akan memperbarui ini dalam beberapa hari mendatang dengan pemikiran saya, dan kami dapat mengambilnya dari sana.

Kami mengalami beberapa masalah sesekali terkait dengan ejekan. Sekarang @jonnyreeves telah melakukan kerja keras untuk benar-benar mengekstraksi modul, tidakkah masuk akal untuk memindahkan modul ke dalam repo jika itu miliknya? Kemudian kita bisa memindahkan semua diskusi yang berkaitan dengan ejekan di sana, dan menutup masalah di sini. Hal ini terutama untuk meringankan beban administrasi.

Kami mengalami beberapa masalah sesekali terkait dengan ejekan. Sekarang @jonnyreeves telah melakukan kerja keras untuk benar-benar mengekstraksi modul, tidakkah masuk akal untuk memindahkan modul ke dalam repo jika itu miliknya? Kemudian kita bisa memindahkan semua diskusi yang berkaitan dengan ejekan di sana, dan menutup masalah di sini. Hal ini terutama untuk meringankan beban administrasi.

Itu juga berarti beban administrasi untuk menjaga agar repositori tetap sinkron dengan alat dev, dll.
Mungkin kita harus memastikan bahwa kita telah menyiapkan alat pengembang bersama yang mudah terlebih dahulu? cc: @mantoni

@mroderick @fatso83 Oke, mari kita lihat apakah kita bisa mengeluarkan 2.0 dari pintu.

Saya telah memperbarui ikhtisar Masalah ini untuk mencakup apa yang saya anggap sebagai semua migrasi yang luar biasa (termasuk CJSification dari testsuite, tolong, jika Anda membaca ini - tolong!) - silakan lihat dan beri tahu saya jika Anda setuju dengan karya yang luar biasa.

Selain itu, saya ingin mendapatkan konsensus tentang hal-hal berikut:

1. Haruskah kita menghapus typeOf dan extend dari API publik ( sinon. ), atau haruskah ini menunggu Sinon 3.x yang (saya asumsikan) akan menjalani modernisasi API .
2. Haruskah kita menghapus dukungan/peretasan IE lama dari 2.0? _may_ ini menyederhanakan migrasi karena kami dapat menghapus kode 'fakeXDM' - Saya belum melihat lebih dekat sehingga saya belum dapat memperkirakan pekerjaan ini.
3. Apakah pengiriman situs dokumen baru merupakan prasyarat rilis 2.0? Saya khawatir itu tidak memiliki banyak daya tarik :)

Terima kasih semuanya.

@jonnyreeves : Kamu pasti sibuk malam ini . Saya memiliki liburan panjang di depan saya, jadi saya pasti bisa membantu dengan migrasi luar biasa dari test suite (ada "tetapi" di bawah).

Mengenai poin Anda:

1. Mereka harus pergi. Saya pikir ini sudah cukup banyak diselesaikan (ref, ikhtisar di atas).
2. Mari kita definisikan "legacy IE" terlebih dahulu. Versi < 10, atau seluruh paket sinon-ie ? IE9 masih dikirimkan dengan beberapa alternatif CORS aneh yang disebut XDR. Jika ada orang yang masih ingin mendukung versi IE yang dirilis sebelum 2012 mereka selalu dapat menggunakan cabang 1.x, saya kira. Tidak yakin apa yang Anda maksud dengan XDM? Saya tidak yakin untuk versi browser mana sinon-ie diperlukan, jadi saya tidak bisa terlalu bombastis tentang paket yang tidak diperlukan. Kita harus yakin dengan konsekuensinya.
3. Dokumentasi _adalah_ titik sakit saat ini, tetapi saya agak tidak yakin apa yang harus saya katakan di sini. Saya bisa mulai menggali ke #991 sebelum membantu dengan poin lain di atas. Memiliki tempat untuk mendorong dokumen akan membuat hidup lebih baik.

Penasaran seperti apa statusnya? Sepertinya tidak ada banyak kemajuan sejak ~6 bulan yang lalu; Saat ini saya bergantung pada pra-rilis karena berbagai alasan (memfungsikan dukungan Simbol menjadi sangat besar) — Saya tidak bermaksud untuk mendorong, tetapi sederhana 'adatimeline' / 'belum ada timeline' akan bagus! <3

@ELLIOTTCABLE karena kami tidak memiliki dana, tidak ada

1. Meskipun Anda melihat "... direferensikan pada 8 Jul 2016" di atas, itu hanya berarti bahwa komentar pertama dalam daftar berasal dari tanggal tersebut. Edisi terbaru, #1235, merujuk ini "12 hari yang lalu".
2. Daftar masalah hampir selesai - tidak seperti setengah tahun yang lalu.

Jadi ... kami mencapai suatu tempat, tetapi mengawasi perbaikan bug untuk versi sebelumnya, serta pasokan fitur baru yang konstan, menyedot banyak waktu pemeliharaan kami. Hanya meneliti dan menulis ini membutuhkan waktu setengah jam pada akhirnya

Pada dasarnya, setelah melihat daftar di atas hanya ada dua masalah utama yang tersisa:

• "Migrate fake_server and friends" (90% terselesaikan, tinggal sedikit lagi - lihat di atas).
• Publikasikan situs web (lihat #1220: satu hal kecil, sangat mudah, dan satu tugas sedang untuk diperebutkan)

Saya pikir sebagian besar tanda centang pembuka lainnya di atas terkait dengan rilis IE lama (6-10) yang saya yakin tidak akan didukung, berdasarkan diskusi di #1221, sehingga dapat diabaikan. Akan membahas itu sekarang.

@sinonjs/sinon-core: komentar sebelumnya membuat saya sadar bahwa kami memiliki beberapa masalah di atas yang kemungkinan tidak akan kami selesaikan berdasarkan diskusi di #1221:

1. Hapus dukungan/solusi IE Legacy?
2. Memperbaiki xdomain

Peduli jika saya membuat PR untuk menghapus bit IE lama jika kita tidak akan menyentuhnya? Saya akan berasumsi xdomain dapat berakhir di pengisian lahan historis juga, karena itu sebagian besar merupakan peretasan mirip-CORS khusus-IE, sehingga dapat dihapus?

@fatso83 Ahhhh, k. Saya melewatkan komentar yang diperbarui pada Masalah yang dirujuk. Saya harap mengulas ini untuk saya bermanfaat bagi Anda!

Tidak terkait: Sepertinya sebagian dari ini adalah mengabaikan dukungan untuk IE6. Itu sangat disayangkan. Ah baiklah, c'est la marche du progrès! /=

Kami pada dasarnya ada di sana, situs dokumen memiliki masalah sendiri.

Hey chaps - apa saja yang menghalangi kami untuk menandai 2.0 sebagai rilis sinon "stabil" dan membunuh 1.x? :)

Pikir kami ingin # 1297 sebagai hal terakhir.

ETA tentang itu? Saya sarankan kami mengirimkan paling lambat minggu depan, menunda satu fitur itu jika tidak selesai.

Kalian cantik. <3