Saya melihat masalah yang sama persis. Tes akan lulus dan kemudian mocha hang. Lihat CI Travis saya:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

Saya juga memperhatikan masalah yang sama ini pada video-dev / hls.js - mocha hanya hang setelah lulus tes:
https://travis-ci.org/video-dev/hls.js/builds/282590422

Apakah kalian membaca catatan rilis? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

Terima kasih. tok buruk situs web mocha tidak diperbarui dengan perubahan yang melanggar ini. Cli berpendapat di sana tidak menyebutkannya.

Selain menyediakan perbaikan cepat (gunakan --exit ), saya setuju mereka menyerahkan masalah inti menemukan tes yang salah kepada pengguna. Saya berjuang dengan itu sendiri sekarang, tetapi ketika meningkatkan versi utama, saya memastikan untuk membaca catatan rilis dan tidak memutakhirkan secara membabi buta

Catatan rilis menyarankan penggunaan why-is-node-running kecuali itu tidak berhasil karena https://github.com/mafintosh/why-is-node-running/issues/7

Terkena ini juga. Saya memahami alasan di balik perubahan ke default , dan terima kasih telah menaikkan versi mayor, tetapi mengingat bahwa why-is-node-running ditinggalkan dan rusak, ini mungkin bukan perubahan yang paling ramah pengguna.

Halo semua,

Pertama, saya ingin meminta maaf atas jalur pemutakhiran yang kasar pada poin ini - kami sangat setuju bahwa Mocha harus memberi tahu pengguna apa yang membuat tes tetap berjalan (dan bahkan tidak perlu membiarkan proses tetap terbuka; itu bisa saja menjadi alasan untuk mengembalikan kegagalan setelah selesai), tetapi belum menemukan cara yang sepenuhnya memuaskan untuk melakukannya. Versi 4 tidak mendapatkan jumlah waktu yang ingin kami masukkan ke dalamnya, karena itu diminta oleh CI kami yang gagal karena perubahan pada penginstal PhantomJS 1.x (package-lock.json mungkin akan mencegah ini jika kami melakukannya) itu disiapkan sebelumnya, tetapi kami masih tidak dapat membuatnya berfungsi ). why-is-node-running adalah satu-satunya alat yang kami temukan dapat membantu, tetapi kami rasa kami tidak dapat mengintegrasikannya (antara persyaratan --expose-internals dan kurangnya cara yang baik untuk mendapatkan keluarannya secara terprogram); Saya telah menemukan bahwa itu berfungsi jika Anda mengikuti beberapa langkah:

• jalankan Mocha dengan --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha )
• buat file tes pertama Anda (misalnya terdaftar di mocha.opts ) berisi (atau setidaknya dimulai dengan) after(require('why-is-node-running'))

... jadi lebih baik daripada tidak sama sekali (meskipun saya akan melihat apakah saya dapat memperbarui catatan rilis untuk menjelaskan ini lebih detail), tetapi jika ada yang tahu opsi yang lebih baik, beri tahu kami!

Juga maaf atas dokumentasi situs yang hilang - kami akan memperbaruinya secepat mungkin. (Setelah # 2987 selesai, kami bahkan dapat menjadikannya sebagai bagian otomatis dari skrip versi / terbitkan kami!)

@Cantik_bugil

borisov<strong i="7">@glossy</strong>:~/test/mocha $ node --version
v6.11.3

borisov<strong i="8">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --version
4.0.0

borisov<strong i="9">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --expose-internals test.spec.js 
  error: unknown option `--expose-internals'

Edit:

Ini bekerja:

node --expose-internals ./node_modules/.bin/mocha test.spec.js

Benar, maaf saya tidak mengerti tentang itu - --expose-internals adalah opsi Node yang dapat digunakan dengan menjalankan node --expose-internals ./node_modules/mocha/bin/_mocha alih-alih ./node_modules/.bin/mocha . Itu juga sesuatu yang bisa kita perbaiki, karena Mocha meneruskan flag tertentu ke Node dan kita bisa menambahkan --expose-internals ke flag tersebut.

Membuat mochajs / mochajs.github.io # 81 dan # 3045 untuk melacak pembaruan dokumentasi dan bendera Node Mocha. Akan membuat masalah ini tetap terbuka setidaknya sampai dokumentasi diperbarui.

@ScottFreeCode Anda mungkin ingin menyebutkan bahwa --expose-internals hanya berfungsi untuk node <= 6. Mudah-mudahan orang dapat menurunkan versi ke node 6 sementara sehingga mereka dapat menemukan timer apa yang perlu dibatalkan atau tidak direferensikan , atau soket yang perlu unref 'ed. Anda mungkin juga ingin mengarahkan orang ke hook after dan afterEach untuk melakukan pembersihan.

(apakah ada hook "setelah" global yang dipanggil mocha ketika semua pengujian selesai?)

Bagaimanapun, saya menghargai bantuannya, dan terima kasih untuk Mocha!

Anda mungkin ingin menyebutkan bahwa --expose-internals hanya berfungsi untuk node <= 6.

Apakah kamu yakin Saya menguji dengan Node 8.6.0. Meskipun tidak di semua OS, jadi saya rasa saya harus menjalankan setiap kotak yang saya miliki dan memeriksa tiga kali ...

Berikut adalah Intisari dengan panduan kasar untuk mengatasi hal ini untuk saat ini.

Apakah kamu yakin Saya menguji dengan Node 8.6.0. Meskipun tidak di semua OS, jadi saya rasa saya harus menjalankan setiap kotak yang saya miliki dan memeriksa tiga kali ...

Ini "berfungsi" karena memicu keluaran dari modul, tetapi sebenarnya tidak memberi saya banyak informasi, terlepas dari versi Node.js.

Saya akan menambahkan beberapa pembaruan ke situs, tetapi silakan lihat komentar saya yang akan datang di # 3045.

Ini "berfungsi" karena memicu keluaran dari modul, tetapi sebenarnya tidak memberi saya banyak informasi, terlepas dari versi Node.js.

Ini memberikan stacktrace yang berguna untuk setTimeout dan setImmediate , tetapi tidak ada info nyata sama sekali untuk hal-hal lain seperti server mendengarkan (seperti yang baru-baru ini saya temukan ketika mencoba memahami bagaimana ia melakukan apa itu perbuatan). Contoh "async-dump" pada intinya memiliki keuntungan nyata dalam hal bekerja untuk semuanya (dan tidak memerlukan --expose-internals ), meskipun hanya dapat digunakan pada versi Node yang lebih baru.

Saya kira saran umum saya adalah "jika Anda menarik rambut Anda, tambahkan saja --exit dan rileks". Maka jangan gunakan untuk proyek Anda berikutnya: wink:

... dan ini dokumentasinya

Maaf untuk mengomentari PR tertutup lagi, tetapi mungkin ada solusi yang ramah pengguna di sini:

Seseorang bisa mencatat peringatan tentang perilaku yang diubah setelah pelari selesai selama 3 detik atau lebih, tetapi prosesnya tidak keluar.
Hanya perlu menambahkan setTimeout() setelah runner selesai dan memanggil timeout.unref () untuk memastikan batas waktu ini tidak mencegah proses keluar. Jika batas waktu dieksekusi, inilah waktunya untuk peringatan 😉

Saya telah mempertimbangkannya tetapi saya khawatir itu akan menyebabkan masalah lain dengan reporter atau integrasi lain ... Saya tidak dapat membuktikan itu tidak akan terjadi.

Jika Anda masih mengalami masalah dan why-is-node-running tidak berfungsi dengan benar, lihat wtfnode .

Paket itu bekerja lebih baik untuk saya.

Saya dapat melihat bagaimana pengujian yang ada tiba-tiba berhenti keluar dapat mengganggu (untuk sedikitnya). Saya melihat penyebutan tentang perilaku baru di catatan rilis .

Saya menemukan perubahan itu secara tidak sengaja dengan pengujian baru yang memaksa saya untuk memastikan bahwa saya memanggil redis.quit () dalam fungsi after () dan saya sangat senang dengan perilaku baru, yang tampaknya benar dan sesuai untuk saya.

Saya tidak perlu menggunakan [intisari ini] kali ini, tetapi seperti yang telah disebutkan oleh @boneskull , sepertinya itu bisa sangat berguna ketika tidak jelas tugas asinkron mana yang belum selesai dan menahan proses agar tidak keluar.

Saya harus mengakui bahwa saya tidak begitu memahami masalah dalam tiket referensi yang ada di balik perubahan perilaku baru ini.

AFAICT, ini ada hubungannya dengan penolakan Janji yang tidak tertangani. Tapi maafkan saya, jika Anda tidak menyelesaikan Janji yang diberikan untuk tes Mocha, maka Mocha tidak akan berhasil atau melanjutkan (jika --bail disetel) dari tes itu, bukan? Jadi itu harus berupa Promise bersarang yang diimplementasikan dengan buruk yang tidak memiliki penangan penolakan, tetapi kode yang memuatnya harus diselesaikan.

Jika ini masalahnya, saya tidak melihat bagaimana tugas Mocha untuk mendeteksi masalah tersebut. Dan jika menerapkan beberapa sihir untuk mendeteksi isu-isu, yang dapat membuat saat ini (benar-ditulis) tes menggantung tanpa batas waktu, maka yang ajaib harus opt-dalam perilaku, tidak opt-out satu - yaitu --no-exit daripada --exit .

Saya melihat semua pengujian saya menggunakan driver resmi node-mongodb-native yang menggantung karena driver itu mengumpulkan koneksi dan tidak menutup semuanya pada .close() , tampaknya merupakan desain. Pengujian saya berfungsi dengan baik, tetapi tidak ada ketergantungan (atau bukan? Saya tidak tahu pasti fakta bahwa memiliki soket atau deskriptor file yang tertinggal sampai skrip keluar dari tempat lain - bukan?). Jadi apa yang saya uji di sini? Kode saya, atau kode orang lain? Saya pikir saya sedang menguji sendiri, tetapi ternyata tidak.

Tentu, saya dapat menambahkan bendera --exit , tetapi orang berikutnya mungkin tidak, dan bagaimanapun juga, sepertinya salah bahwa saya dapat menulis tes yang sangat bagus dengan kode yang sangat bagus sedang diuji, dan masih memiliki beberapa penyebab ketergantungan acak tes saya untuk menggantung tanpa batas.

Jika saya menambahkan process.exit() di hook after() , pengujian saya tidak akan hang, tetapi kemudian akan rusak parah dengan --watch (mungkin fitur lain), tidak hanya mencegah saya mengawasi perubahan, tetapi mengeluarkan saya ke dalam cangkang tanpa kursor.

Mungkin saja saya yang tidak mengerti di sini (pasti ada banyak yang tidak saya dapatkan, dan banyak orang telah terlibat, jadi saya cenderung berpikir begitu :)), saya hanya merasa seperti ini secara keseluruhan hal ini kurang ... benar ...?

Bersulang :)

EDIT: Mengingat perilaku ini, apakah ada cara bagi saya untuk memeriksa di dalam tes Mocha jika dijalankan dengan --watch sehingga saya dapat memastikan untuk tidak memanggil process.exit() dan merusak barang?

@DanielSmedegaardBuus TL; DR pada solusinya: letakkan --exit di file mocha.opts . (Biasanya ini adalah solusi untuk apa pun yang perlu selalu disetel saat Mocha dijalankan, sebagai tip yang lebih umum.) Klarifikasi yang lebih detail tentang perubahan ini: di bawah.

2640 adalah tentang penolakan promise, tidak dimaksudkan untuk melakukan apa pun, tetapi membuatnya konsisten dengan pengecualian sinkron yang muncul dari kode pengujian asinkron non-promise, dan belum diterapkan .

Ini tentang pengujian yang menyiapkan resource, listener, atau pekerjaan yang sedang berlangsung dan tidak membersihkannya, terlepas dari apakah promise digunakan dalam implementasinya dan / atau dalam pengujian. Sebagai contoh:

Saya memiliki tes untuk API berdasarkan websockets, yang mencakup membuka dan menutup koneksi. API ini bermasalah dan tidak menutup koneksi dengan benar, tetapi lulus pengujian karena pengujian tidak benar-benar memiliki cara untuk menyatakan bahwa koneksi yang mendasarinya diperlakukan dengan benar. (Jika saya hanya menguji kode saya sendiri secara ketat, saya dapat memverifikasi itu menggunakan ketergantungan dalam apa yang saya anggap keliru sebagai cara yang benar; Saya menguji dengan websocket asli secara tepat untuk menangkap masalah dengan kebenaran penggunaan di tempat pertama - tes integrasi untuk melengkapi tes unit.) Saya menangkap kesalahan itu ketika saya beralih ke perilaku --no-exit (dari Mocha 3; sekarang default di Mocha 4) dan menemukan bahwa jika saya menjalankan tes tersebut Node tidak akan menutup karena koneksi websocket masih mendengarkan.

(Memang benar, mungkin saja kesalahannya terletak pada ketergantungan daripada pada kode Anda sendiri, tetapi meskipun demikian, ada manfaatnya mengetahui bahwa sebelum Anda mengirimkan dengan versi tertentu dari ketergantungan itu - seperti yang disinggung di atas, ini adalah lebih dapat diterapkan untuk pengujian integrasi daripada pengujian unit, tetapi idealnya sebuah proyek memiliki keduanya.)

Ini tidak selalu diperlukan, tentu saja - dalam beberapa kasus, sumber daya seperti ini mungkin dimaksudkan untuk dibiarkan hidup hingga proses dihentikan, atau mungkin membuat Node tetap hidup meskipun tidak ada pembersihan lain yang benar-benar penting, atau mungkin bagian dari kumpulan sumber daya yang menggunakan kembali anggota individu dan tidak perlu membersihkan kumpulan secara keseluruhan - dalam kasus seperti itu --exit akan benar . Alasan perubahan perilaku default adalah untuk meningkatkan visibilitas masalah tersebut: sebelumnya, Anda mungkin tidak akan pernah tahu untuk mencoba --no-exit dan memeriksa jenis kesalahan ini, sekarang Anda akan menemukannya secara default dan dapat --exit jika Anda menentukan bahwa perilakunya benar (atau setidaknya tidak perlu dikhawatirkan).

Ada, tentu saja, ada sesuatu masalah dengan "perbaikan" yang menggantung begitu saja saat ini terjadi tidak terlalu informatif . Kami masih harus mencari tahu apakah kami dapat mengintegrasikan beberapa cara untuk benar-benar memeriksa secara terprogram untuk hal-hal yang masih berjalan (sehingga peringatan atau kesalahan yang tepat dapat diberikan) yang akan berfungsi pada semua versi Node yang didukung tanpa mengganggu apa pun yang mungkin masih berjalan. membersihkan atau menutup saat Mocha mencapai akhir.

Maaf, tapi ini sangat membuat frustrasi. Saya hanya mencoba mencari tahu mengapa moka tidak mau keluar. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit menautkan ke why-is-node-running , jadi sekarang saya telah pergi, mencoba menggunakan modul itu, melihat pesan samar "Kesalahan: Tidak dapat menemukan modul ' internal / linkedlist '... (stack trace) ", dan setelah mengikuti lubang kelinci mencoba mencari tahu mengapa --expose-internals tidak berfungsi, saya berakhir di https://github.com/mochajs/mocha/ issues / 3045 untuk menemukan solusi yang seharusnya, tetapi why-is-node-running memberi tahu saya bahwa ada 1 pegangan yang diketahui yang membuatnya tetap terbuka, dan beberapa pegangan yang tidak diketahui, tetapi tidak mencantumkan apa pun.

Ini mungkin bukan tempat yang tepat untuk mengemukakan hal ini, tetapi dokumen moka seharusnya tidak merekomendasikan solusi yang memerlukan banyak googling dan masalah penyelaman untuk mulai bekerja . Saya mencoba mengeluarkan dan menambahkannya, dengan perilaku yang sangat tidak konsisten. Demi pengguna masa depan dan kewarasan saya:

package.json:

"scripts": {
    "test": "mocha --exit"
}

Itu yang terbaik yang bisa saya lakukan.

@jeffvandyke Saya memahami rasa frustrasi Anda dan mengalami masalah yang sama - tetapi jika Anda memiliki pernyataan di balik janji, Anda dapat menghargai perubahan ini.

Saya memiliki sejumlah spesifikasi yang memiliki perilaku asinkron yang tidak stabil. Bergantung pada urutan run dari spesifikasi saya, error penolakan janji yang tidak tertangkap akan dicatat ke konsol dan kemudian di-scroll hingga tidak terlihat oleh ratusan pengujian lain yang lulus, atau instance node akan ditutup sebelum penolakan terjadi.

Setelah menghapus --exit dari mocha.opts , janji yang ditolak akan mencatat kesalahan dengan andal, dan menyorot bug tersebut.

Saya tahu, banyak rasa sakit yang dibagikan :) Perilaku yang didokumentasikan Mocha sebenarnya terdengar benar bagi saya, tetapi meskipun 5 pengujian saya tampak cukup sederhana, hanya menggunakan node-fetch untuk menguji api, saya masih tidak yakin mengapa mocha tidak keluar , meskipun mereka semua lulus dengan sukses (ya, mereka juga bisa gagal). Saya dapat menghabiskan lebih banyak waktu untuk mencoba mencari tahu mengapa why-is-node-running tidak berfungsi, tetapi saya lelah memikirkan kode orang lain, jadi saya pikir saya akan memberi diri saya istirahat untuk saat ini.

Saya mungkin akan terus bermain dengannya, dan jika saya bisa mendapatkan sesuatu yang dapat direproduksi, saya mungkin akan membuka edisi baru, meskipun tidak ada janji.

akan merekomendasikan debugger inspektur node yang baru ... ini memiliki jejak async yang baik.

Yay! Ternyata wtfnode jauh lebih baik dalam menjelaskan hal ini. Saya menemukan bahwa ketika menggunakan node-fetch, saya harus menelepon result.text() atau .json() atau koneksi tetap terbuka. Menjalankan wtfnode ./node_modules/.bin/_mocha dan menekan Ctrl-C menunjukkan koneksi yang terbuka.

Saya pikir akan lebih mudah jika dokumen merekomendasikan paket ini daripada why-is-node-running .

Saran lain: Saya sangat suka ide @andywer yang memiliki semacam peringatan jika mocha dos tidak keluar. Akan lebih baik jika mocha bahkan dapat menggunakan wtfnode entah bagaimana untuk membuat daftar pegangan aktif yang menjaga node tetap hidup setelah beberapa waktu berlalu.

Apapun hal yang harus dilakukan, saya pikir itu sampah yang harus saya lihat sejauh ini untuk mencari tahu mengapa moka tidak mau keluar. Bagaimanapun, saya telah memberikan saran saya :)

Hai kawan,
Saya pikir fitur ini masih mungkin tidak bekerja dengan benar, ini adalah tes dasar yang paling saya bisa memikirkan dan mocha masih gagal untuk keluar dengan sendirinya. --no-exit adalah opsi default yang sangat baik dan saya mendukungnya, tetapi entah saya gagal memahami apa yang saya lakukan salah atau ada sesuatu yang secara intrinsik salah dengan moka dan itu mencegah untuk menutup bahkan pengujian yang paling sederhana.

describe('describe', function() { it('it', function(done) { done(); }); });

ringkasan: --exit berhasil, --no-exit tidak pernah menutup tes apa pun .

Dalam kasus saya, saya menggunakan aplikasi Koa , dan menguji dengan Mocha 4 + Supertest .

Saya harus menutup server bersama dengan done panggilan mengikuti catatan rilis "Untuk menghindari kesalahan positif dan mendorong praktik pengujian yang lebih baik".

Sebelum:

request(app.listen())
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, done)

Setelah:

const server = app.listen()

request(server)
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, () => {
    server.close()
    done()
  })

Semoga membantu somenoe.

Saya melakukan beberapa bootstrap untuk moka sebelum setiap tes. Pada dasarnya memulai server HTTP kecil dalam proses yang sama.

Apakah ada acara yang dapat saya ikuti untuk menghentikannya setelah Mocha berhenti berjalan? Saya hanya ingin menutupnya, tetapi hanya pada saat itu.

Saya suka ide di balik fitur ini btw .. ini adalah ujian yang bagus untuk melihat apakah Anda memiliki acara yang menggantung.

@evert Tidakkah bekerja menutup server di after ?

Apakah ada 'setelah semuanya' global yang berjalan setelah moka selesai? Saya mungkin melewatkannya! Tidak dapat menemukannya di dokumen.

Ya, ada hook after global.

https://mochajs.org/#root -level-hooks

Terima kasih! Saya melewatkannya, maaf: Saya tidak tahu istilah untuk ctrl-f.

wtfnode tidak benar-benar berfungsi untuk saya. Yang bisa saya lihat hanyalah bahwa beberapa PID yang dimulai oleh moka tergantung.

Di sisi lain, @boneskull gist berfungsi: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745. Terima kasih!

wtfnode harus dijalankan terhadap _mocha , bukan mocha .

Terima kasih atas --exit . Itu memperbaikinya untuk saya.

masukkan skrip ini di package.json:
"script": {
"test": "mocha --exit"
}

Saya mencoba berbagai solusi yang disebutkan di utas ini:

• why-is-node-running tidak menghasilkan output
• wtfnode menghasilkan keluaran tetapi tidak cukup untuk menentukan di mana deskriptor File / Soket / Server / Pengatur Waktu dibuat dalam kode
• async_hooks kesalahan metode debug
• menambahkan –exit ke hasil bendera baris cmd mocha di keluar

Jadi ikuti @ProfJigsaw dan gunakan –exit, itulah yang saya lakukan. Akan lebih bagus jika ada peningkatan dengan moka, setidaknya cara untuk mencari tahu di mana masalah itu dan bagaimana mengatasinya.

Itulah gunanya debugger, IMO. Bagaimana Anda men-debug skrip Anda sendiri jika skrip tersebut tidak pernah keluar?

https://github.com/GoogleChromeLabs/ndb adalah proyek yang keren.

Di luar topik: Saya suka tiket ini, hanya untuk informasi tentang alat pemecahan masalah yang terus diberikannya! :)

@borisovg Bayangkan betapa hebatnya tiket ini jika benar-benar memberikan solusi! :)
@boneskull Apakah ada beberapa fitur debugger "list File descriptors / Sockets / Servers / Timer" yang tidak saya ketahui?

@mjgs berhasil bagi saya - wtfnode berfungsi tetapi hanya jika saya menggunakannya dengan biner _mocha , bukan mocha one:

$ wtfnode ./node_modules/.bin/_mocha my-shitty-code.spec.js 


  tests
    ✓ some test


  1 passing (5ms)

^C[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Servers:
  - :::8080 (HTTP)
    - Listeners:
      - request: (anonymous) @ /home/borisov/test/my-shitty-code.js:4
- Intervals:
  - (5000 ~ 5 s) (anonymous) @ /home/borisov/test/my-shitty-code.js:8

@borisovg Terima kasih atas teladan super Anda. Dalam kasus saya wtfnode menunjukkan ada koneksi mongo terbuka, tetapi semua koneksi mongo di my-shitty-code.js telah ditutup, jadi masalahnya adalah dari tempat lain, dan wtfnode tidak memberikan info yang cukup tentang di mana itu. dari.

Jika wtfnode menunjukkan bahwa koneksi mongo db terbuka, maka itu terbuka. Mengapa Anda menganggap itu salah?

@evert Saya pikir Anda mungkin telah salah menafsirkan apa yang saya tulis

Contoh minimal bagus untuk ilustrasi, dan sebenarnya berguna untuk melihat keluaran yang serupa dengan apa yang Anda lihat, tetapi dalam kode nyata yang telah ditulis selama bertahun-tahun, hubungan ini tidak begitu mudah ditemukan. Senang mengetahui bahwa ada koneksi mongo yang masih terbuka, tetapi untuk benar-benar menemukannya bukanlah hal yang sepele. Saya akhirnya menemukan beberapa koneksi terbuka, tetapi mereka jauh lebih dalam dalam kode daripada tingkat permukaan di mana semua koneksi telah ditutup secara verifikasi, wtfnode tidak membantu dalam mengidentifikasi di mana mereka hanya ada dengan mendaftar jalur modul luwak. Saya masih memiliki beberapa untuk dilacak, hanya berdasarkan nomor port, tapi saya berharap.

Saya mengalami masalah ini saat menulis fungsi Tanpa Server yang berkomunikasi dengan Firebase. Ternyata Admin SDK mereka mempertahankan pegangan terbuka tanpa batas. Karena perubahan ini (dan saran selanjutnya untuk menggunakan wtfnode , saya dapat mengidentifikasi fakta itu dan menghemat banyak sakit kepala (dan biaya) di masa mendatang.

Menurut pendapat saya, akan sangat membantu untuk memasukkan semacam logika "jika hang selama X lama dan tidak memiliki keluaran, lemparkan beberapa teks ke stdout". Saya tidak yakin seberapa layak atau berapa banyak bandwidth yang tersedia untuk menghasilkan peningkatan seperti itu, tapi saya pikir itu mungkin membantu mengurangi beberapa frustrasi awal "wtf terjadi dengan mocha saya!"

var timers = sinon.useFakeTimers({
    now: new Date().getTime(),
    shouldAdvanceTime: true,
});

Jika saya lupa timers.restore(); prosesnya hang selamanya.

Berdasarkan dokumentasi @pgilad yang dikirim ke sini, bagi saya ada solusi yang lebih bersih. Seperti yang dikatakan dalam dokumenter :

Untuk menghindari kesalahan positif dan mendorong praktik pengujian yang lebih baik, Mocha tidak akan lagi otomatis mati sendiri melalui proses.exit () ketika dianggap harus dilakukan berjalan.

Solusi yang lebih bersih maka akan membuat fungsi after global ( after luar fungsi describe ), saya akan merekomendasikan dalam file terpisah seperti exit-mocha.js atau exit-mocha jika Anda mau. Callback dikirim ke setelah Anda dapat memaksa keluar dari proses node anggun yang akan keluar tanpa kesalahan apa pun. File tersebut dapat dikirim ke mocha cli seolah-olah itu adalah file tes lain (ini dapat mensimulasikan flag --exit )

exit-mocha.js atau exit-mocha

after('Exit mocha gracefully after finishing all tests execution'. function () {
  // Exit node process
  process.exit();
});

Kemudian Anda dapat menjalankan tes mocha seperti:

mocha exit-mocha test/**/*.spec.js

atau

mocha exit-mocha.js test/**/*.spec.js

Penting bahwa jika Anda menggunakan wildcard untuk nama file tes seperti yang saya lakukan dengan test/**/*.spec.js bahwa nama file exit-mocha TIDAK cocok dengan pola wildcard, jika tidak, tidak akan mungkin bagi Anda untuk menggunakannya sebagai "bendera"

@ vctr90 Itu solusi yang bagus, meskipun Anda memiliki periode di mana Anda harus memiliki koma dalam contoh Anda. Juga semuanya dapat diubah menjadi kode golf menjadi hanya:

after('Exit mocha gracefully after finishing all tests execution', process.exit);

Adakah kemungkinan seorang pengembang bisa ikut campur tentang mengapa menambahkan ini ke Mocha yang tepat akan menyakiti seseorang (karena jelas akan membantu banyak orang)?

@machineghost Saya menyukai perilaku baru karena 2 alasan:

1. Hampir tidak ada perpustakaan lain yang akan keluar setelah 'menyelesaikan tugasnya'. Misalnya, menutup server Node TCP tidak akan secara otomatis memicu keluar. Dengan cara itu, ini konsisten dengan perpustakaan lain.
2. Jika node tidak keluar, itu berarti masih ada event yang menunggu untuk diselesaikan. Mungkin lebih baik untuk mencoba dan meningkatkan kode Anda sehingga semuanya menjadi bersih setelah setiap pengujian. Itu juga bisa menunjukkan bahwa ada kebocoran memori.

Jadi ketika saya mengalami ini, ini adalah insentif bagi saya untuk mencoba dan membersihkan kode saya sehingga tidak terjadi.

Perspektif Anda tentang hal ini mungkin 'saya tidak peduli tentang kebocoran memori', atau 'ini tidak layak diperbaiki dalam aplikasi saya'. Jika Anda termasuk dalam kategori ini, cara termudah adalah menghasilkan mocha.opts dan menambahkan --exit .

Sepertinya bagi saya ini tentang membuat lebih banyak suara, bukan sinyal: dalam sebagian besar kasus, tidak ada aplikasi yang akan menjadi lebih baik karena Mocha digantung di bagian akhir.

Jika Mocha akan menjadi default, sepertinya defaultnya akan berakhir ketika tes (dan semua panggilan after / afterEach ) telah selesai. Tidak melakukannya hanya untuk memberi tahu orang-orang "hei, lingkungan pengujian buatan Anda adalah buatan" tidak menguntungkan sebagian besar (atau bahkan minoritas yang layak) pengguna.

Jika orang benar-benar ingin men-debug koneksi yang tidak tertutup maka tampaknya itulah yang harus Anda berikan opsi. Tapi sepanjang waktu, apakah benar-benar menguntungkan pengguna perpustakaan untuk membingungkan orang lain dengan (apa artinya mengatakan) "Anda berada dalam lingkungan pengujian dan salah satu dari satu miliar kemungkinan hal terbuka"?

Dengan kata lain, jika Anda akan memberi tahu 99% orang yang mengalami ini "cukup gunakan --exit " maka mungkin --exit seharusnya tidak menjadi opsi khusus yang harus Anda lakukan sediakan ... mungkin perilaku default harus melayani 99% kasus pengguna (sementara tentu saja masih memberi pengguna _option_ --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out )?

Maksudku, jika Anda membuat bahwa pilihan, realistis seberapa sering Anda pikir orang bahkan akan lulus?

PS Saya baru saja menemukan ini: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection. Jika Anda melihat jawaban kedua, perilaku di Mocha ini secara langsung menyebabkan setidaknya satu pengguna (yang bukan saya, dan saya bersumpah saya tidak mengenal mereka: Saya baru saja menemukan ini karena keberuntungan setelah membuat posting terakhir saya) untuk menambahkan salah kode non-tes ("fitur" ini membuat mereka salah mengira perlu memanggil knex.destroy() di aplikasi mereka).

Versi ringkasan:

Orang Baik: Anda mungkin biasanya tidak perlu memanggil knex.destroy () secara eksplisit - ini tersirat oleh dokumentasi itu sendiri yang mengatakan (penekanan milik saya):

Orang Baik: kutipan dokumen

Orang yang Bingung: Jika saya tidak memanggil knex.destroy () skrip saya akan hang. Lalu apa artinya kita tidak perlu secara eksplisit memanggil knex.destroy ()

Orang Baik: Ah, Anda hanya menyebutkan di tempat lain bahwa ini untuk Mocha. Untuk penggunaan server biasa, Anda tidak perlu merobohkan kumpulan koneksi - untuk Mocha, Anda mungkin ingin melihat hook pembongkaran global, lihat futurestud.io/tutorials/…

Tetapi untuk lebih jelasnya, pengguna ini memiliki lingkungan kerja, dan karena Mocha (pada dasarnya) memberi tahu mereka bahwa kode mereka yang sangat bagus itu salah, mereka kehilangan siapa yang tahu berapa banyak waktu untuk mencoba memecahkan bug yang mereka buat dengan menghancurkan koneksi mereka. Dan itu hanya satu orang sial yang kebetulan melakukannya di depan umum, dan yang kebetulan saya lihat.

Jadi, saya rasa yang ingin saya sampaikan adalah, ini bukan hanya tentang apa yang benar secara filosofis, juga bukan hanya beberapa kebisingan yang mengaburkan sinyal yang berguna ... perilaku ini sebenarnya menyebabkan kerusakan , dan membuat pemrogram membuang waktu untuk memiringkan di kincir angin.

Maaf, saya salah mengira titik lelah Anda adalah pertanyaan yang jujur. Saya menyesal menjawab. Mungkin pengembang bisa mengunci utas ini.

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" bekerja untuk saya. Memang --exit adalah solusi yang sangat bagus. Saya menggunakan versi 5.2.0 dalam proyek saya.

Adakah cara untuk mendapatkan efek yang setara dengan menggunakan bendera --exit saat menggunakan mocha "secara terprogram ?"

Saya tidak melihat opsi terdokumentasi untuk exit / noexit, atau cara umum untuk meneruskan string bendera saat menggunakan NodeJS API.

Mengikuti pola opsi lain, saya mencoba:

const mocha = new Mocha({
    exit: true,
});

tetapi tidak bisa mendapatkan efek yang diinginkan.

Pemeriksaan sepintas dari https://github.com/mochajs/mocha/blob/master/lib/mocha.js tampaknya menunjukkan bahwa opsi ini perlu ditambahkan tidak hanya ke dokumentasi, tetapi juga ke sumbernya.

Selain menyediakan perbaikan cepat (gunakan --exit ), saya setuju mereka menyerahkan masalah inti menemukan tes yang salah kepada pengguna. Saya berjuang dengan itu sendiri sekarang, tetapi ketika meningkatkan versi utama, saya memastikan untuk membaca catatan rilis dan tidak memutakhirkan secara membabi buta

Bagaimana tepatnya Anda lulus? Ini adalah skrip package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } dan tidak berfungsi

Selain menyediakan perbaikan cepat (gunakan --exit ), saya setuju mereka menyerahkan masalah inti menemukan tes yang salah kepada pengguna. Saya berjuang dengan itu sendiri sekarang, tetapi ketika meningkatkan versi utama, saya memastikan untuk membaca catatan rilis dan tidak memutakhirkan secara membabi buta

Bagaimana tepatnya Anda lulus? Ini adalah skrip package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } dan tidak berfungsi

Memiliki masalah yang sama dan saya pikir saya bukan satu-satunya. Saya hanya harus pindah --keluar pada akhirnya.
Ini tidak berhasil:
penutup istanbul ./node_modules/mocha/bin/_mocha --exit - test / .test.jsIni berhasil saya:penutup istanbul ./node_modules/mocha/bin/_mocha - test / .test.js --exit

exit tidak melakukan apa-apa saat menjalankan Mocha secara terprogram, fwiw. proses ini dipaksa keluar oleh CLI wrapper, bukan Mocha-the-library.