मैं ठीक वैसी ही समस्या देख रहा हूं। टेस्ट पास होंगे और फिर मोचा बस लटक जाएगा। मेरा ट्रैविस CI देखें:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

मैंने वीडियो-देव / hls.js पर भी यही समस्या देखी - मोचा केवल परीक्षणों को पारित करने के बाद लटका देता है:
https://travis-ci.org/video-dev/hls.js/builds/282590422

क्या आप लोगों ने रिलीज़ नोट्स पढ़े? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

धन्यवाद। टो ख़राब मोचा वेबसाइट इस ब्रेकिंग बदलाव से अपडेट नहीं है। वहां मौजूद कुलियों का उल्लेख नहीं है।

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

जारी नोटों में https://github.com/mafintosh/why-is-node-running/issues/7 के कारण काम नहीं करने के अलावा why-is-node-running का उपयोग करने का सुझाव है।

इससे भी मारा। मैं डिफ़ॉल्ट में परिवर्तन के पीछे के why-is-node-running को छोड़ दिया जाता है और टूट जाता है, यह सबसे उपयोगकर्ता के अनुकूल परिवर्तन नहीं हो सकता है।

नमस्ते,

सबसे पहले, मैं इस बिंदु पर किसी न किसी अपग्रेड पथ के लिए माफी चाहता हूं - हम निश्चित रूप से सहमत हैं कि मोचा को उपयोगकर्ता को यह बताना चाहिए कि परीक्षण क्या चल रहा है (और फिर उसे प्रक्रिया को खुला रखने की आवश्यकता नहीं होगी; यह सिर्फ हो सकता है; ऐसा होने के बाद विफलता लौटने का एक कारण हो सकता है), लेकिन अभी तक ऐसा करने के लिए पूरी तरह से संतोषजनक तरीका नहीं मिला है। संस्करण 4 को उस समय की राशि नहीं मिली जो हम इसमें डालना चाहते थे, क्योंकि इसे हमारे CI द्वारा फैंटमजस 1.x के इंस्टॉलर में बदलाव के कारण विफल होने के संकेत दिए गए थे। यह पहले से ही सेट अप है, लेकिन हम अभी भी इसे काम नहीं कर सकते हैं )। why-is-node-running एक ऐसा उपकरण था जिसे हमने मदद करने के लिए पाया था, लेकिन हमें नहीं लगता कि हम इसे एकीकृत कर सकते हैं ( --expose-internals की आवश्यकता के बीच और प्रोग्राम को इसके आउटपुट प्राप्त करने के लिए एक अच्छे तरीके की कमी); मैंने पाया है कि यह काम करता है यदि आप एक दो चरणों का पालन करते हैं:

• --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha ) के साथ मोचा चलाएं
• अपनी पहली परीक्षा फ़ाइल बनाएं (जैसे mocha.opts में सूचीबद्ध) (या कम से कम शुरुआत के साथ) after(require('why-is-node-running'))

... तो यह कुछ भी नहीं से बेहतर है (हालांकि मैं देखूंगा कि क्या मैं इसे और अधिक विस्तार से वर्णन करने के लिए रिलीज़ नोट्स को अपडेट कर सकता हूं), लेकिन अगर कोई बेहतर विकल्प जानता है तो कृपया हमें बताएं!

साइट के दस्तावेज़ गुम होने पर भी खेद है - हम इसे जल्द से जल्द अपडेट कर देंगे। (एक बार # 2987 हो जाने के बाद हम इसे अपने संस्करण / प्रकाशन स्क्रिप्टिंग का एक स्वचालित हिस्सा भी बना सकते हैं!)

@ScottFreeCode

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'

संपादित करें:

यह काम:

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

ठीक है, खेद है कि मैं के बारे में स्पष्ट नहीं था - --expose-internals एक नोड विकल्प है कि चलाकर इस्तेमाल किया जा सकता है node --expose-internals ./node_modules/mocha/bin/_mocha के बजाय ./node_modules/.bin/mocha । यह भी कुछ हम तय कर सकते हैं, क्योंकि मोचा नोड पर कुछ झंडे गुजरता है और हम उन झंडे में --expose-internals जोड़ सकते हैं।

क्रमशः प्रलेखन और मोचा के नोड झंडे को ट्रैक करने के लिए mochajs / mochajs.github.io # 81 और # 3045 बनाया गया। प्रलेखन अद्यतन होने तक कम से कम इस मुद्दे को खुला रखेंगे।

@ScottFreeCode आप उल्लेख करना चाह सकते हैं कि --expose-internals केवल नोड के लिए काम करता है <= 6. उम्मीद है कि लोग नोड 6 को अस्थायी रूप से डाउनग्रेड कर सकते हैं ताकि वे पा सकें कि किस टाइमर को रद्द करने की आवश्यकता है या फिर ' unref का एड। आप लोगों को सफाई करने के लिए after और afterEach हुक देने के लिए भी कहना चाह सकते हैं।

(क्या कोई वैश्विक "हुक" के बाद मोचा कॉल करता है जब सभी परीक्षण पूर्ण होते हैं?)

किसी भी घटना में, मैं मदद की सराहना करता हूं, और मोचा के लिए धन्यवाद!

आप यह उल्लेख करना चाह सकते हैं कि --expose-internals केवल नोड <= 6 के लिए काम करता है।

क्या आपको यकीन है? मैंने Node 8.6.0 के साथ परीक्षण किया। यद्यपि सभी OSes पर नहीं है, इसलिए मुझे लगता है कि मुझे हर बॉक्स में आग लगानी चाहिए और ट्रिपल-चेक ...

यहाँ इस समय के लिए

क्या आपको यकीन है? मैंने Node 8.6.0 के साथ परीक्षण किया। यद्यपि सभी OSes पर नहीं है, इसलिए मुझे लगता है कि मुझे हर बॉक्स में आग लगानी चाहिए और ट्रिपल-चेक ...

यह "काम करता है" में यह मॉड्यूल से आउटपुट को ट्रिगर करता है, लेकिन यह वास्तव में मुझे बहुत अधिक जानकारी नहीं देता है, भले ही नोड्स .js. के संस्करण की परवाह किए बिना।

मैं साइट पर कुछ अपडेट जोड़ने जा रहा हूं, लेकिन कृपया मेरी आगामी टिप्पणियों को # 3045 पर देखें।

यह "काम करता है" में यह मॉड्यूल से आउटपुट को ट्रिगर करता है, लेकिन यह वास्तव में मुझे बहुत अधिक जानकारी नहीं देता है, भले ही नोड्स .js. के संस्करण की परवाह किए बिना।

यह setTimeout और setImmediate लिए एक उपयोगी स्टैकट्रेस देता है, लेकिन अन्य चीजों के लिए बिल्कुल भी कोई वास्तविक जानकारी नहीं है जैसे कि एक श्रवण सर्वर (जैसा कि मैंने अभी हाल ही में पाया, यह समझने की कोशिश कर रहा है कि यह कैसे कर रहा है? करते हुए)। जीस्ट में "एसिंक्स-डंप" उदाहरण में हर चीज के लिए काम करने के मामले में वास्तविक लाभ है (और --expose-internals आवश्यकता नहीं है), भले ही यह नोड के नए संस्करणों पर उपयोगी हो।

मुझे लगता है कि मेरी सामान्य सलाह "यदि आप अपने बालों को बाहर निकाल रहे हैं, तो बस --exit और आराम करें"। फिर अपने अगले प्रोजेक्ट के लिए इसका इस्तेमाल न करें: पलक:

... और यहाँ डॉक्स हैं

बंद पीआर पर फिर से टिप्पणी करने के लिए क्षमा करें, लेकिन यहां उपयोगकर्ता के अनुकूल समाधान हो सकता है:

धावक 3s या तो समाप्त होने के बाद बदले हुए व्यवहार के बारे में चेतावनी लॉग कर सकता है, लेकिन प्रक्रिया से बाहर नहीं निकला।
बस धावक समाप्त होने के बाद setTimeout() जोड़ने की आवश्यकता होगी और यह सुनिश्चित करने के लिए टाइमआउट. unref () कॉल करें कि यह टाइमआउट प्रक्रिया को बाहर निकलने से नहीं रोकता है। यदि टाइमआउट निष्पादित हो जाता है तो यह चेतावनी के लिए समय है execut

मैंने माना है कि लेकिन मैं सावधान हूं कि यह पत्रकारों या अन्य एकीकरण के साथ अन्य समस्याओं का कारण बनेगा ... मैं यह साबित नहीं कर सकता कि यह नहीं होगा।

यदि आपको अभी भी समस्या हो रही है और why-is-node-running सही काम नहीं कर रहा है, तो wtfnode की जाँच करें।

उस पैकेज ने मेरे लिए बहुत बेहतर काम किया।

मैं देख सकता हूं कि कैसे मौजूदा परीक्षण अचानक बाहर निकलना बंद कर सकते हैं (कम से कम कहने के लिए) डिस्कनेक्टिंग हो सकता है। मुझे जारी नोटों में नए व्यवहार के बारे में एक उल्लेख दिखाई देता है।

मैंने अपने आप को नए परीक्षणों के साथ गलती से बदल दिया, जिससे मुझे यह सुनिश्चित करने के लिए मजबूर होना पड़ा कि मैंने बाद में () फ़ंक्शन में redis.quit () कहा और मैं निश्चित रूप से नए व्यवहार से प्रसन्न हूं, जो मुझे सही और उचित लगता है।

इस बार मुझे [इस gist] का उपयोग करने की आवश्यकता नहीं थी, लेकिन जैसा कि पहले ही @boneskull द्वारा उल्लेख किया गया है, ऐसा लगता है कि यह वास्तव में उपयोगी हो सकता है जब यह स्पष्ट नहीं है कि async कार्य पूरा नहीं हुआ है और बाहर निकलने से प्रक्रिया को पकड़े हुए है।

मुझे स्वीकार करना चाहिए कि मैं संदर्भित टिकटों में उन मुद्दों को नहीं समझता जो इस नए व्यवहार परिवर्तन के पीछे हैं।

AFAICT, इसका अनहेल्ड प्रॉमिस रिजेक्ट के साथ कुछ करना है। लेकिन क्षमा करें, अगर आप मोचा टेस्ट के लिए दिए गए एक प्रॉमिस को हल नहीं करते हैं, तो मोचा उस टेस्ट से न तो सफल होगा और न ही जारी रहेगा (यदि --bail सेट है), है ना? तो यह कुछ खराब तरीके से लागू होने वाला नेस्टेड प्रॉमिस होना चाहिए, जिसमें रिजेक्शन हैंडलर नहीं है, लेकिन किसी भी तरह कोड को हल करना होगा।

अगर ऐसा है, तो मुझे नहीं लगता कि उन मुद्दों का पता लगाना मोचा का काम कैसे है। और अगर उन मुद्दों का पता लगाने के लिए कुछ जादू को लागू किया जाए, जो वर्तमान (सही तरीके से लिखे गए) परीक्षण अनिश्चित काल के लिए लटक सकते हैं, तो वह जादू एक ऑप्ट-इन व्यवहार होना चाहिए, न कि ऑप्ट-आउट एक - यानी --no-exit बजाय --exit ।

मैं अपने सभी परीक्षणों को आधिकारिक नोड-मोंगोडब-देशी ड्राइवर को लटकाते हुए देख रहा हूं क्योंकि ड्राइवर पूल .close() पर बंद नहीं करता है, प्रतीत होता है कि डिजाइन हो। मेरे परीक्षण सही तरीके से व्यवहार कर रहे हैं, लेकिन एक निर्भरता नहीं है (या यह है? मैं एक तथ्य के लिए जरूरी नहीं जानता कि यह खराब व्यवहार है क्योंकि एक स्क्रिप्ट कहीं और बाहर है - क्या आप? तो मैं यहां क्या परीक्षण कर रहा हूं? मेरा कोड, या किसी और का? मुझे लगा कि मैं अपना परीक्षण कर रहा हूं, लेकिन स्पष्ट रूप से नहीं।

निश्चित रूप से, मैं --exit ध्वज जोड़ सकता हूं, लेकिन अगला आदमी नहीं हो सकता है, और किसी भी तरह से, यह गलत लगता है कि मैं पूरी तरह से ठीक परीक्षण के साथ पूरी तरह से ठीक परीक्षण लिख सकता हूं, और अभी भी कुछ यादृच्छिक निर्भरता का कारण है मेरे परीक्षण अनिश्चित काल के लिए लटकने के लिए।

अगर मैं एक जोड़ने process.exit() फाइनल में after() हुक, मेरे परीक्षण रखती हूँ नहीं है, लेकिन फिर इसके साथ बुरी तरह विभाजित करेंगे --watch न केवल (संभवतः अन्य सुविधाओं), मुझे परिवर्तनों को देखने से रोक रहा है, लेकिन मुझे एक बिना खोल के बाहर निकाल रहा है।

यह बहुत अच्छी तरह से हो सकता है कि मैं यहाँ क्लूलेस हूं (निश्चित रूप से ऐसा बहुत कुछ है जो मुझे नहीं मिल रहा है, और बहुत सारे लोग इसमें शामिल हो गए हैं, इसलिए मैं ऐसा सोचना चाहूंगा :)), मुझे बस यह पूरा लग रहा है बात काफी नहीं है ... सही है ...?

चियर्स :)

EDIT: इस व्यवहार को देखते हुए, क्या मेरे लिए मोचा टेस्ट के अंदर जांचने का कोई तरीका है कि क्या इसे --watch साथ चलाया जा रहा है ताकि मैं process.exit() कॉल न कर सकूं और चीजों को तोड़ सकूं?

@DanielSmedegaardBuus TL; समाधान पर DR: --exit mocha.opts फ़ाइल में डालें। (यह आमतौर पर किसी भी चीज के लिए समाधान है जिसे मोचा चलाने पर हमेशा एक सामान्य टिप के रूप में सेट करने की आवश्यकता होती है।) यह परिवर्तन क्या है, इसके बारे में अधिक विस्तृत स्पष्टीकरण: नीचे।

2640 वादा अस्वीकार के बारे में है, कुछ भी करने का इरादा नहीं है, लेकिन उन्हें गैर-वादा एसिंक्रोनस परीक्षण कोड से फेंके गए तुल्यकालिक अपवादों के अनुरूप बनाते हैं, और अभी तक लागू नहीं किया गया है ।

यह संसाधनों, श्रोताओं या चल रहे कामों को स्थापित करने और इसे साफ न करने वाले परीक्षणों के बारे में है, भले ही उनके कार्यान्वयन और / या परीक्षण में वादों का उपयोग किया गया हो। उदाहरण के लिए:

मेरे पास वेबस्कैट पर आधारित एपीआई के लिए एक परीक्षण है, जिसमें कनेक्शन खोलना और बंद करना शामिल है। यह एपीआई छोटी गाड़ी थी और कनेक्शन को बंद नहीं कर रही थी, लेकिन मेरे परीक्षणों को पारित कर दिया क्योंकि परीक्षणों में वास्तव में यह दावा करने का कोई तरीका नहीं था कि अंतर्निहित कनेक्शन को सही तरीके से व्यवहार किया गया था। (यदि मैंने केवल अपने स्वयं के कोड का कड़ाई से परीक्षण किया था, तो मैं सत्यापित कर सकता था कि यह निर्भरता का उपयोग कर रहा है कि मैंने गलती से सही तरीके से सोचा था; मैं वास्तविक वेबस्कैट के साथ परीक्षण कर रहा था, हालांकि पहली बार में उपयोग शुद्धता के साथ मुद्दों को पकड़ने के लिए - एकीकरण परीक्षण यूनिट परीक्षणों को पूरक करने के लिए।) मैंने उस त्रुटि को पकड़ा, जब मैं --no-exit व्यवहार (Mocha 3 का;) अब Mocha 4 में डिफ़ॉल्ट) में बदल गया और पता चला कि अगर मैं उन परीक्षणों को चलाता तो नोड बंद नहीं होता क्योंकि वेबसैट कनेक्शन अभी भी सुन रहा है।

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

यह हमेशा आवश्यक नहीं है, निश्चित रूप से - कुछ मामलों में, इस प्रकृति के एक संसाधन को प्रक्रिया के मारे जाने तक जीवित रहने का मतलब हो सकता है, या नोड को जीवित रख सकता है, भले ही संसाधन का कोई अन्य सफाई वास्तव में मायने नहीं रखता, या एक संसाधन पूल का हिस्सा हो सकता है जो व्यक्तिगत सदस्यों को पुन: उपयोग करता है और पूल को पूरी तरह से साफ करने की आवश्यकता नहीं है - ऐसे मामलों में --exit सही होगा । डिफ़ॉल्ट व्यवहार के परिवर्तन का कारण इस तरह के मुद्दों की दृश्यता को बढ़ाना था: इससे पहले, आप शायद --no-exit कोशिश करना और इस प्रकार की त्रुटियों के लिए जांच नहीं करेंगे, अब आप डिफ़ॉल्ट रूप से उनमें भाग लेंगे। और यदि आप यह निर्धारित करते हैं कि व्यवहार सही है (या कम से कम इसके बारे में चिंता करने लायक नहीं है) तो --exit हो सकते हैं।

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

मुझे क्षमा करें, लेकिन यह बहुत निराशाजनक था। मैं सिर्फ यह जानने की कोशिश कर रहा था कि मोचा बाहर क्यों नहीं आएगा। https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit why-is-node-running लिंक करता है, इसलिए अब मैं चला गया हूं, उस मॉड्यूल का उपयोग करने की कोशिश की, 'गुप्त' मॉड्यूल नहीं मिल सकता है। आंतरिक / लिंक्डलिस्ट '... (स्टैक ट्रेस) ", और खरगोश छेद का अनुसरण करने के बाद यह पता लगाने की कोशिश कर रहा है कि --expose-internals काम नहीं करता है, मैं https://github.com/mochajs/mocha/ पर हवा करता हूं why-is-node-running मुझे बताता है कि इसे खुला रखने के लिए 1 ज्ञात हैंडल है, और कुछ अज्ञात हैंडल हैं, लेकिन कुछ भी सूचीबद्ध नहीं करता है।

इसे लाने के लिए यह सही जगह नहीं हो सकती है, लेकिन मोचा के डॉक्स को ऐसे समाधानों की सिफारिश नहीं की जानी चाहिए, जिन्हें काम करने के लिए इस तरह के googling और डाइविंग की आवश्यकता होती है । मैं बहुत ही असंगत व्यवहार के साथ चीजों को बाहर निकालने और उन्हें जोड़ने की कोशिश कर रहा था। भविष्य के उपयोगकर्ताओं और मेरी पवित्रता के लिए:

package.json:

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

यही सबसे अच्छा मैं कर सकता हूं।

@ जेफविन्डीके मैं आपकी निराशा को समझता हूं और उन्हीं मुद्दों से

मेरे पास कई ऐनक थे जिनमें परतदार async व्यवहार था। मेरे चश्मे के रन ऑर्डर के आधार पर, अनचेक किए गए वादे अस्वीकृति त्रुटियों को कंसोल में लॉग इन किया जाएगा और फिर दृष्टि के बाहर स्क्रॉल किया जाएगा जो कि पारित होने से पहले सैकड़ों अन्य परीक्षण, या नोड उदाहरण बंद हो जाएंगे।

मेरे mocha.opts --exit से

मुझे पता है, बहुत से साझा दर्द :) मोचा का प्रलेखित व्यवहार वास्तव में मेरे लिए सही लगता है, लेकिन फिर भी मेरे 5 परीक्षण काफी सरल लगते हैं, बस एक एपी परीक्षण करने के लिए नोड-भ्रूण का उपयोग करते हुए, मैं अभी भी अनिश्चित हूं कि मोचा बाहर क्यों नहीं निकलता है , भले ही वे सभी सफलतापूर्वक उत्तीर्ण हों (हाँ, वे असफल भी हो सकते हैं)। मैं यह जानने में अधिक समय व्यतीत कर सकता हूं कि why-is-node-running काम क्यों नहीं कर रहा है, लेकिन मैं अन्य लोगों के कोड के बारे में सोचकर थक गया हूं, इसलिए मुझे लगता है कि मैं खुद को अभी के लिए एक विराम दूंगा।

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

नए नोड इंस्पेक्टर के डिबगर की सिफारिश करेंगे ... इसमें अच्छे एसिंक्स निशान हैं।

वाह! इस पर प्रकाश बहाने में wtfnode की ओर result.text() या .json() कॉल करना होगा या कनेक्शन खुला रहेगा। wtfnode ./node_modules/.bin/_mocha चलना और Ctrl-C दबाने से खुले कनेक्शन का पता चला।

मुझे लगता है कि यह आसान होता अगर डॉक्स why-is-node-running बजाय इस पैकेज की सिफारिश करते।

एक और सुझाव: अगर मोचा से बाहर नहीं निकले तो मुझे @andywer को किसी तरह की चेतावनी देने का विचार पसंद है। कुछ समय बीत जाने के बाद नोड को जीवित रखने वाले सक्रिय हैंडल को सूचीबद्ध करने के लिए यदि मोचा wtfnode का भी उपयोग कर सकता है तो यह मीठा होगा।

जो भी सही चीज होनी चाहिए, मुझे लगता है कि यह कचरा है कि मुझे यह पता लगाने के लिए बहुत दूर जाना था कि मोचा बाहर क्यों नहीं निकलेंगे। वैसे भी, मैंने अपने सुझाव दिए हैं :)

हाय दोस्तों,
मुझे लगता है कि इस सुविधा अभी भी ठीक से काम नहीं हो सकता है, यह सबसे बुनियादी परीक्षण मैं के बारे में सोच सकता है और मोचा अभी भी अपने आप में बाहर निकलने के लिए विफल रहता है है। --no-exit एक उत्कृष्ट डिफ़ॉल्ट विकल्प है और मैं इसके लिए सबकुछ हूं, लेकिन या तो मैं यह समझने में असफल हो रहा हूं कि मैं क्या गलत कर रहा हूं या कोई चीज आंतरिक रूप से मोचा के साथ गलत है और यह सबसे सरल परीक्षणों को भी बंद करने से रोक रहा है।

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

सारांश: --exit काम करता है, --no-exit कभी भी कोई परीक्षण बंद नहीं करता है।

मेरे मामले में मैं कोआ एप्लिकेशन का उपयोग कर रहा हूं, और मोचा 4 + सुपरटेस्ट के साथ परीक्षण कर रहा हूं।

मुझे रिलीज़ नोटों के बाद "झूठे सकारात्मकता से बचने और बेहतर परीक्षण प्रथाओं को प्रोत्साहित करने के लिए" done कॉल के साथ बस सर्वर को

इससे पहले:

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

उपरांत:

const server = app.listen()

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

आशा है कि यह somenoe में मदद करता है।

मैं हर टेस्ट से पहले मोचा के लिए कुछ बूटस्ट्रैपिंग कर रहा हूं। मूल रूप से उसी प्रक्रिया में थोड़ा HTTP सर्वर शुरू करना।

क्या कोई ऐसा कार्यक्रम है जिसे मैं बंद कर सकता हूं क्योंकि मोचा के चलने पर यह बंद हो सकता है? मैं बस इसे बंद करना चाहता हूं, लेकिन सिर्फ उस समय।

मुझे इस फीचर के पीछे के विचार से प्यार है .. यह देखने के लिए कि क्या आपके पास झूलने की घटना है, यह एक अच्छी परीक्षा है।

@evert after में सर्वर बंद करने का काम नहीं करता है?

क्या मोचा होने के बाद चलने वाली वैश्विक 'सब कुछ' के बाद है? मुझे वो याद आ गया होगा! डॉक्स में नहीं मिल सका।

हां, वैश्विक after हुक है।

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

धन्यवाद! मुझे याद आया कि, क्षमा करें: / ctrl-f के लिए शर्तों को नहीं जानता था।

wtfnode ने वास्तव में मेरे लिए काम नहीं किया। मैं देख सकता था कि मोचा द्वारा शुरू की गई कुछ पीआईडी ​​लटक गई थी।

दूसरी ओर, @boneskull gist ने काम किया: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745। धन्यवाद!

wtfnode _mocha विरुद्ध चलने की आवश्यकता है, mocha ।

--exit के लिए धन्यवाद। इसने मेरे लिए इसे ठीक कर दिया।

इस स्क्रिप्ट को package.json में दर्ज करें:
"स्क्रिप्ट": {
"परीक्षण": "मोचा - एक्सिट"
}

मैंने इस सूत्र में वर्णित विभिन्न उपायों को आजमाया:

• क्यों-नोड-रनिंग कोई आउटपुट नहीं देता है
• wtfnode आउटपुट उत्पन्न करता है लेकिन यह निर्धारित करने के लिए पर्याप्त नहीं है कि कोड में फ़ाइल डिस्क्रिप्टर / सॉकेट / सर्वर / टाइमर कहाँ बनाए गए हैं
• async_hooks डीबग विधि त्रुटियाँ
• mxha cmd लाइन फ्लैग में जोड़ने से परिणाम निकलता है

इसलिए @ProfJư का पालन करें और उपयोग करें, यही मैं कर रहा हूं। महान होगा अगर मोचा द्वारा एक सुधार था, हालांकि कम से कम यह पता लगाने का एक तरीका है कि मुद्दे कहां हैं और उन्हें कैसे हल किया जाए।

यह एक डिबगर के लिए, IMO है। यदि वे कभी बाहर नहीं हुए तो आप अपनी स्वयं की लिपियों को कैसे डिबग करेंगे?

https://github.com/GoogleChromeLabs/ndb एक अच्छा प्रोजेक्ट है।

ऑफ-टॉपिक: मुझे यह टिकट बहुत पसंद है, बस समस्या निवारण साधनों की जानकारी के लिए यह देता रहता है! :)

@borisovg कल्पना करें कि अगर यह वास्तव में समाधान प्रदान करता है तो यह टिकट कितना शानदार होगा! :)
@boneskull क्या कुछ "सूची फ़ाइल विवरणक / सॉकेट / सर्वर / टाइमर" डीबगर सुविधा है जिससे मैं अवगत नहीं हूं?

@mjgs ने मेरे लिए यह किया - wtfnode काम किया, लेकिन केवल जब मैंने इसे _mocha बाइनरी के साथ इस्तेमाल किया, न कि mocha एक:

$ 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 अपने वास्तव में सुपर उदाहरण के लिए धन्यवाद। मेरे मामले में wtfnode से पता चलता है कि एक mongo कनेक्शन खुला है, लेकिन मेरे my-shitty-code.js में सभी mongo कनेक्शन बंद कर दिए गए हैं, इसलिए समस्या कहीं और से है, और wtfnode पर्याप्त नहीं है जहाँ यह है से।

यदि wtfnode इंगित करता है कि एक मोंगो डीबी कनेक्शन खुला है, तो यह खुला है। आप इसे गलत क्यों मानेंगे?

@ क्या मुझे लगता है कि आपने जो कुछ भी लिखा है, उसका गलत मतलब

न्यूनतम उदाहरण चित्रण के लिए महान हैं, और यह वास्तव में आपके द्वारा देखे जा रहे समान आउटपुट को देखने के लिए उपयोगी है, लेकिन वास्तविक कोड में जो कई वर्षों से लिखे गए हैं, ये कनेक्शन खोजने में आसान नहीं हैं। यह जानना अच्छा है कि अभी भी मोंगो कनेक्शन खुले हैं, लेकिन वास्तव में उन्हें खोजने के लिए गैर-तुच्छ है। मुझे अंततः कुछ खुले कनेक्शन मिले, लेकिन वे सतह के स्तर की तुलना में कोड में बहुत अधिक गहरे थे जहां सभी कनेक्शन मौखिक रूप से बंद हो गए थे, wtfnode ने यह पहचानने में मदद नहीं की कि वे कहाँ थे वे केवल मानगो मॉड्यूल पथ को सूचीबद्ध करके मौजूद थे। मेरे पास अभी भी कुछ ट्रैक करने के लिए है, केवल पोर्ट नंबर के आधार पर, लेकिन मुझे उम्मीद है।

मैं इस मुद्दे में एक सर्वरहीन समारोह है कि Firebase के साथ संचार लिखने में भाग गया। अपने व्यवस्थापक को चालू करता है SDK अनिश्चित काल के लिए एक खुला हैंडल रखता है। इस परिवर्तन (और wtfnode का उपयोग करने के लिए बाद के सुझाव के कारण, मैं उस तथ्य की पहचान करने में सक्षम था और सड़क से नीचे अपने आप को एक टन सिरदर्द (और लागत) बचाता था।

मेरी राय में, "यदि यह एक्स लंबे समय तक लटका रहता है और किसी भी आउटपुट को टेक्स्ट को स्टडआउट करने के लिए नहीं फेंकता है" तर्क को शामिल करने के लिए बहुत उपयोगी होगा। मैं अनिश्चित हूं कि इस तरह के सुधार के लिए कितना संभव है या कितना बैंडविड्थ उपलब्ध है, लेकिन मुझे लगता है कि "mtha के साथ wtf चल रहा है" कुछ शुरुआती निराशा को कम करने में मदद मिल सकती है!

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

अगर मैं timers.restore(); भूल जाऊं तो प्रक्रिया हमेशा के लिए लटक जाती है।

यहां भेजे गए प्रलेखन @pgilad के आधार पर, मेरे लिए एक क्लीनर समाधान है। जैसा कि डॉक्यूमेंटेशन कहता है:

झूठी सकारात्मकता से बचने और बेहतर परीक्षण प्रथाओं को प्रोत्साहित करने के लिए, मोचा अब प्रक्रिया के माध्यम से स्वचालित रूप से खुद को नहीं मारेगा। () जब यह सोचता है कि इसे चलाना चाहिए।

एक क्लीनर समाधान तो यह एक वैश्विक after फ़ंक्शन (एक after किसी भी describe फ़ंक्शन) के बाहर बनाने के लिए होगा, मैं exit-mocha.js तरह एक अलग फ़ाइल में सिफारिश करूंगा exit-mocha अगर आप करेंगे। आपके द्वारा भेजी गई कॉलबैक एक इमानदारी से नोड प्रक्रिया से बाहर निकलने के लिए बाध्य कर सकती है जो बिना किसी त्रुटि के बाहर निकलने वाली है। फ़ाइल को mocha cli में भेजा जा सकता है जैसे कि यह एक और परीक्षण फ़ाइल थी (यह --exit ध्वज का अनुकरण कर सकती है)

exit-mocha.js या exit-mocha

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

तब आप मोचा परीक्षण निष्पादित कर सकते हैं जैसे:

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

या

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

यह महत्वपूर्ण है कि अगर आप वाइल्डकार्ड का उपयोग कर रहे हैं जैसे कि परीक्षण फ़ाइलों के नाम के लिए मैंने test/**/*.spec.js साथ किया था कि exit-mocha फ़ाइल का नाम वाइल्डकार्ड पैटर्न से मेल नहीं खाता है, अन्यथा, यह नहीं होगा आपके लिए इसे "ध्वज" के रूप में उपयोग करना संभव है

@ vctr90 यह एक महान समाधान है, हालांकि आपके पास एक अवधि है जहां आपको अपने उदाहरण में अल्पविराम होना चाहिए। यह भी पूरी बात कोड गोल्फ-एड नीचे हो सकता है:

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

क्या कोई मौका है कि कोई देव इस बात पर झंकार कर सकता है कि मोचा के साथ इसे जोड़ने से किसी को चोट पहुंचेगी (क्योंकि यह स्पष्ट रूप से बहुत से लोगों की मदद करेगा)।

@ मचिनीघोस्त मुझे 2 कारणों से नया व्यवहार पसंद है:

1. 'अपना काम करने' के बाद लगभग कोई अन्य पुस्तकालय बाहर नहीं निकलेगा। उदाहरण के लिए, एक नोड टीसीपी सर्वर को बंद करने से स्वचालित रूप से एक निकास ट्रिगर नहीं होगा। इस तरह, यह अन्य पुस्तकालयों के अनुरूप है।
2. यदि नोड बाहर नहीं निकलता है, तो इसका मतलब है कि अभी भी घटनाओं का समाधान होने की प्रतीक्षा है। अपने कोड को आज़माने और बेहतर बनाने के लिए शायद बेहतर है ताकि प्रत्येक परीक्षण के बाद चीजें साफ हो जाएं। यह सुझाव भी दे सकता है कि मेमोरी लीक है।

इसलिए जब मैं इसमें भाग लेता हूं, तो मेरे लिए यह प्रयास करने और अपने कोड को साफ करने के लिए एक प्रोत्साहन है, इसलिए ऐसा नहीं होता है।

इस पर आपका दृष्टिकोण 'मैं स्मृति लीक की परवाह नहीं करता' हो सकता है, या 'यह मेरे आवेदन में फिक्सिंग के लायक नहीं है'। यदि आप इस श्रेणी में सबसे आसान हैं, तो mocha.opts और --exit जोड़ना है।

यह सिर्फ मुझे लगता है कि यह अधिक शोर करने के बारे में है, संकेत नहीं: महत्वपूर्ण मामलों में किसी का ऐप बेहतर नहीं होने वाला है क्योंकि मोचा अंत में लटका हुआ है।

यदि मोचा डिफ़ॉल्ट होने वाला है, तो ऐसा लगता है कि परीक्षण समाप्त होने पर इसे समाप्त होना चाहिए (और सभी after / afterEach कॉल) समाप्त हो गए हैं। लोगों को यह बताने के लिए नहीं कि "आपके कृत्रिम परीक्षण का माहौल कृत्रिम है" उपयोगकर्ताओं के बहुमत (या यहां तक ​​कि एक सभ्य अल्पसंख्यक) को भी लाभ नहीं पहुंचाता है।

यदि लोग वास्तव में बिना कनेक्शन के डिबग करना चाहते हैं, तो ऐसा लगता है कि ऐसा मामला होना चाहिए जो आप के लिए एक विकल्प प्रदान करते हैं। लेकिन बाकी के सभी समय में, क्या पुस्तकालय के उपयोगकर्ताओं को वास्तव में सभी को भ्रमित करने के लिए लाभ होता है (किस मात्रा में कहने के लिए) "आप परीक्षण के माहौल में हैं और एक अरब संभव चीजों में से एक खुली है"?

इसे दूसरे तरीके से रखने के लिए, यदि आप 99% लोगों को बताने जा रहे हैं जो इस "बस --exit " का उपयोग करते हैं तो शायद --exit को एक विशेष विकल्प नहीं होना चाहिए जो आपके पास है प्रदान करें ... हो सकता है कि डिफ़ॉल्ट व्यवहार 99% उपयोगकर्ता मामलों की सेवा के लिए होना चाहिए (हालांकि अभी भी उपयोगकर्ताओं को --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out का _option_ दे रहा है)?

मेरा मतलब है, अगर आपके द्वारा किए गए विकल्प, वास्तविक कितनी बार आपको लगता है कि लोग भी इसे पारित होगा?

PS मैं अभी इस पर आया हूं: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection। यदि आप दूसरे उत्तर को देखते हैं, तो मोचा में यह व्यवहार सीधे तौर पर कम से कम एक उपयोगकर्ता (जो मैं नहीं हूं, और मैं कसम खाता हूं, मैं उन्हें नहीं जानता हूं: मैं गलत तरीके से अपनी आखिरी पोस्ट करने के बाद भाग्य से मिला) गैर-परीक्षण कोड (इस "सुविधा" ने उन्हें गलत तरीके से knex.destroy() बनाने की आवश्यकता समझी)।

सारांश संस्करण:

अच्छा व्यक्ति: आपको शायद आमतौर पर knex.destroy () को स्पष्ट रूप से कॉल करने की आवश्यकता नहीं है - यह दस्तावेज़ीकरण स्वयं कह रहा है (जोर) द्वारा निहित है:

अच्छा व्यक्ति: उद्धरण डॉक्स

भ्रमित व्यक्ति: अगर मैं knex.destroy () नहीं कहता हूं तो मेरी स्क्रिप्ट लटक जाएगी। तो इसका क्या मतलब है कि हमें knex.destroy () स्पष्ट रूप से कॉल करने की आवश्यकता नहीं है

अच्छा व्यक्ति: आह, आपने केवल कहीं और उल्लेख किया है कि यह मोचा के लिए है। नियमित सर्वर का उपयोग करने के लिए आपको कनेक्शन पूल को फाड़ने की आवश्यकता नहीं है - मोचा के लिए, आप एक वैश्विक फाड़ हुक देखना चाहते हैं, futurestud.io/tutorials/… देखें

लेकिन स्पष्ट होने के लिए, इस उपयोगकर्ता के पास काम करने का माहौल था, और क्योंकि मोचा (अनिवार्य रूप से) ने उन्हें बताया कि उनका बिल्कुल अच्छा कोड गलत था, उन्होंने खो दिया जो जानते हैं कि उनके कनेक्शन को नष्ट करके उनके द्वारा बनाए गए बग को हल करने में कितना समय लगता है। और यह सिर्फ एक अशुभ व्यक्ति है जो इसे सार्वजनिक रूप से करने के लिए हुआ, और जो मैंने देखा।

इसलिए, मुझे लगता है कि मैं जो बताने की कोशिश कर रहा हूं, यह केवल दार्शनिक रूप से सही होने के बारे में नहीं है, और न ही यह है कि कुछ शोर उपयोगी संकेतों को अस्पष्ट कर रहे हैं ... यह व्यवहार वास्तव में नुकसान पहुंचा रहा है , और प्रोग्रामर समय बर्बाद कर रहे हैं। पवनचक्कियों पर।

मुझे क्षमा करें, मैंने एक ईमानदार प्रश्न के लिए आपके थके हुए बिंदु को गलत समझा। मुझे जवाब देने का अफसोस है। हो सकता है कि डेवलपर्स इस थ्रेड को लॉक कर सकते हैं।

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" ने मेरे लिए काम किया। वास्तव में --exit एक बहुत अच्छा समाधान है। मैं अपने प्रोजेक्ट में संस्करण 5.2.0 का उपयोग करता हूं।

क्या मोचा " प्रोग्रामेटिक रूप से " का उपयोग करते समय --exit झंडे के बराबर प्रभाव प्राप्त करने का एक तरीका है?

मुझे बाहर निकलने / नोक्सिट के लिए एक प्रलेखित विकल्प नहीं दिखता है, और न ही NodeJin API का उपयोग करते समय ध्वज स्ट्रिंग में पारित करने का एक सामान्य तरीका।

अन्य विकल्पों के पैटर्न के बाद, मैंने कोशिश की:

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

लेकिन वांछित प्रभाव प्राप्त करने में सक्षम नहीं था।

Https://github.com/mochajs/mocha/blob/master/lib/mocha.js का सरसरी निरीक्षण यह प्रतीत करता है कि इस विकल्प को न केवल दस्तावेज में जोड़ा जाना चाहिए, बल्कि स्रोत से भी जोड़ा जाना चाहिए।

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

आप इसे कैसे पास करते हैं? यह मेरी package.json स्क्रिप्ट है

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } और यह काम नहीं कर रहा है

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

आप इसे कैसे पास करते हैं? यह मेरी package.json स्क्रिप्ट है

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } और यह काम नहीं कर रहा है

एक ही मुद्दा था और मुझे लगता है कि मैं अकेला नहीं हूं। मुझे बस अंत में आना - जाना पड़ा।
यह काम नहीं किया:
istanbul कवर ।/node_modules/mocha/bin/_mocha --exit - test / .test.jइसने मुझे काम किया:istanbul कवर ।/node_modules/mocha/bin/_mocha - परीक्षण / .est.js --exit

exit Mocha को प्रोग्रामेटिक रूप से चलाने पर कुछ नहीं करता है, fwiw। इस प्रक्रिया को सीएलआई रैपर द्वारा बलपूर्वक बाहर किया जाता है, न कि मोचा-ए-लाइब्रेरी द्वारा।