أرى نفس المشكلة بالضبط. ستمر الاختبارات ثم يتوقف المخاوي. انظر بلدي Travis CI:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

لقد لاحظت أيضًا هذه المشكلة نفسها على video-dev / hls.js - توقف mocha بعد اجتياز الاختبارات:
https://travis-ci.org/video-dev/hls.js/builds/282590422

هل قرأتم ملاحظات الإصدار؟ https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

شكر. tok bad لم يتم تحديث موقع mocha بهذا التغيير العاجل. أرجس cli هناك لا تذكر ذلك.

بخلاف تقديم حل سريع (استخدم --exit ) ، أوافق على أنهم تركوا المشكلة الأساسية المتمثلة في العثور على الاختبارات المعيبة للمستخدم. أنا أعاني من ذلك الآن ، ولكن عند ترقية الإصدارات الرئيسية ، أتأكد من قراءة ملاحظات الإصدار وعدم الترقية بشكل أعمى

تشير ملاحظات الإصدار إلى استخدام why-is-node-running إلا أنه لا يعمل بسبب https://github.com/mafintosh/why-is-node-running/issues/7

ضرب هذا أيضا. أتفهم السبب وراء التغيير إلى الإعداد الافتراضي ، وأشكرك على زيادة الإصدار الرئيسي ، ولكن نظرًا لأنه تم التخلي عن why-is-node-running وتعطله ، فقد لا يكون هذا هو التغيير الأكثر سهولة في الاستخدام.

تحية للجميع،

أولاً ، أريد أن أعتذر عن مسار الترقية التقريبي في هذه النقطة - نحن نتفق بالتأكيد على أن موكا يجب أن تخبر المستخدم بما يحافظ على تشغيل الاختبارات (وبعد ذلك لن تحتاج حتى إلى إبقاء العملية مفتوحة ؛ يمكن فقط يكون سببًا لإعادة الفشل بعد الانتهاء) ، ولكن لم يتم العثور على طريقة مرضية تمامًا للقيام بذلك حتى الآن. لم يحصل الإصدار 4 على مقدار الوقت الذي أردنا وضعه فيه ، حيث تمت المطالبة به من خلال فشل CI الخاص بنا بسبب التغييرات في مثبت PhantomJS 1.x (من المحتمل أن يكون package-lock.json منع هذا إذا كان لدينا تم إعداده مسبقًا ، لكننا ما زلنا لا نستطيع تشغيله ). why-is-node-running كانت الأداة الوحيدة التي وجدناها للمساعدة ، لكننا لا نعتقد أنه يمكننا دمجها (بين متطلبات --expose-internals وعدم وجود طريقة جيدة للحصول على مخرجاتها برمجيًا) ؛ لقد وجدت أنه يعمل إذا اتبعت خطوتين:

• قم بتشغيل Mocha بـ --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha )
• اجعل أول ملف اختباري (على سبيل المثال مدرج في mocha.opts ) يحتوي (أو على الأقل يبدأ بـ) after(require('why-is-node-running'))

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

آسف أيضًا بشأن فقد وثائق الموقع - سنقوم بتحديثها في أقرب وقت ممكن. (بمجرد الانتهاء من # 2987 ، يمكننا حتى جعله جزءًا تلقائيًا من إصدارنا / نصوص النشر!)

تضمين التغريدة

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 . هذا أيضًا شيء يمكننا إصلاحه ، نظرًا لأن Mocha يمرر أعلامًا معينة إلى Node ويمكننا إضافة --expose-internals إلى تلك العلامات.

تم إنشاء mochajs / mochajs.github.io # 81 و # 3045 لتتبع تحديث الوثائق وعلامات Mocha Node ، على التوالي. سوف تبقي هذه المشكلة مفتوحة على الأقل حتى يتم تحديث الوثائق.

ScottFreeCode ، قد ترغب في الإشارة إلى أن --expose-internals يعمل فقط مع العقدة <= 6. ونأمل أن يتمكن الأشخاص من الرجوع إلى العقدة 6 مؤقتًا حتى يتمكنوا من العثور على المؤقت الذي يجب إلغاؤه أو عدم إصلاحه ، أو المقابس التي يجب أن تكون unref 'ed. قد ترغب أيضًا في توجيه الأشخاص إلى خطافات after و afterEach لإجراء التنظيف.

(هل هناك خطاف عام "بعد" يستدعي موكا عند اكتمال جميع الاختبارات؟)

على أي حال ، أنا أقدر المساعدة ، وشكرًا لموكا!

قد ترغب في الإشارة إلى أن --expose-internals تعمل فقط مع العقدة <= 6.

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

إليك Gist مع دليل تقريبي للتغلب على هذا في الوقت الحالي.

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

هذا "يعمل" من حيث أنه يقوم بتشغيل الإخراج من الوحدة ، ولكنه في الواقع لا يعطيني الكثير من المعلومات ، بغض النظر عن إصدار Node.js.

سأقوم بإضافة بعض التحديثات إلى الموقع ، ولكن يرجى الاطلاع على تعليقاتي القادمة على # 3045.

هذا "يعمل" من حيث أنه يقوم بتشغيل الإخراج من الوحدة ، ولكنه في الواقع لا يعطيني الكثير من المعلومات ، بغض النظر عن إصدار Node.js.

إنه يوفر ميزة stacktrace مقابل setTimeout و setImmediate ، لكن لا توجد معلومات حقيقية على الإطلاق لأشياء أخرى مثل خادم الاستماع (كما اكتشفت مؤخرًا أثناء محاولتي فهم كيفية قيامه بما هو عليه تفعل). يتميز مثال "التفريغ غير المتزامن" في جوهره بميزة حقيقية من حيث العمل من أجل كل شيء (ولا يتطلب الأمر --expose-internals ) ، على الرغم من أنه يمكن استخدامه فقط على الإصدارات الأحدث من Node.

أفترض أن نصيحتي العامة ستكون "إذا كنت تشد شعرك ، فقط أضف --exit واسترخ". ثم لا تستخدمه لمشروعك التالي: غمزة:

... وهنا المستندات

آسف للتعليق على العلاقات العامة المغلقة مرة أخرى ، ولكن قد يكون هناك حل سهل الاستخدام هنا:

يمكن للمرء تسجيل تحذير حول السلوك المتغير بعد انتهاء العداء لمدة 3 ثوانٍ أو نحو ذلك ، لكن العملية لم تخرج.
ستحتاج فقط إلى إضافة setTimeout() بعد انتهاء العداء واستدعاء timeout.unref () للتأكد من أن هذا المهلة لا يمنع العملية من الخروج. إذا تم تنفيذ المهلة ، فقد حان وقت التحذير 😉

لقد فكرت في ذلك ولكني أخشى أن يتسبب في مشاكل أخرى مع المراسلين أو عمليات تكامل أخرى ...

إذا كنت لا تزال تواجه مشاكل و why-is-node-running لا يعمل بشكل صحيح ، فتحقق من wtfnode .

هذه الحزمة عملت بشكل أفضل بالنسبة لي.

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

اكتشفت التغيير عن طريق الخطأ باختبارات جديدة أجبرتني على التأكد من أنني اتصلت بـ redis.quit () في وظيفة after () وأنا سعيد بالتأكيد بالسلوك الجديد ، الذي يبدو صحيحًا ومناسبًا لي.

لم أكن بحاجة إلى استخدام [هذا الجوهر] هذه المرة ، ولكن كما ذكرنا سابقًا من قبل boneskull ، يبدو أنه قد يكون مفيدًا حقًا عندما لا يكون من الواضح أي المهام غير المتزامنة لم تكتمل

يجب أن أعترف أنني لا أفهم تمامًا المشكلات الواردة في التذاكر المشار إليها والتي تكمن وراء هذا التغيير السلوكي الجديد.

AFAICT ، لها علاقة برفض الوعد غير المعالج. لكن عفواً ، إذا لم تحل الوعد الممنوح لاختبار Mocha ، فلن تنجح Mocha ولن تستمر (إذا تم تعيين --bail ) من هذا الاختبار ، أليس كذلك؟ لذلك يجب أن يكون هناك بعض الوعد المتداخل الذي تم تنفيذه بشكل سيئ والذي لا يحتوي على معالج رفض ، ولكن يجب حل الشفرة الحاوية على أي حال.

إذا كان هذا هو الحال ، فأنا لا أرى كيف أن مهمة Mocha هي اكتشاف هذه المشكلات. وإذا تنفيذ بعض السحر للكشف عن تلك القضايا، الأمر الذي قد يجعل التيار (مكتوبة بشكل صحيح) اختبارات معلقة إلى أجل غير مسمى، فإن ذلك السحر يجب أن يكون التقيد في السلوك، وليس التقيد من أصل واحد - أي --no-exit بدلا من --exit .

أنا أبحث في جميع اختباراتي باستخدام برنامج التشغيل الأصلي node-mongodb الأصلي المعلق لأن اتصالات تجمع السائقين ولا .close() ، يبدو أنه تصميم. تتصرف اختباراتي بشكل صحيح ، لكن التبعية ليست كذلك (أو هل هي كذلك؟ لا أعرف بالضرورة حقيقة أنه من السلوك السيئ وجود مآخذ أو واصفات ملفات باقية حتى يتم الخروج من البرنامج النصي في مكان آخر - أليس كذلك؟). إذن ما الذي أختبره هنا؟ الكود الخاص بي أم شخص آخر؟ ظننت أنني كنت أختبر نفسي ، لكن من الواضح أنني لم أفعل ذلك.

بالتأكيد ، يمكنني إضافة علامة --exit ، لكن الرجل التالي قد لا يفعل ، وفي كلتا الحالتين ، يبدو أنه من الخطأ أن أكتب اختبارات جيدة تمامًا مع كود جيد تمامًا قيد الاختبار ، ولا يزال لدي بعض التبعية العشوائية اختباراتي للتعليق إلى أجل غير مسمى.

إذا أضفت process.exit() في خطاف نهائي after() ، فلن تتعطل اختباراتي ، ولكن بعد ذلك ستنكسر بشكل فظيع مع --watch (ربما ميزات أخرى) ، ليس فقط يمنعني من مشاهدة التغييرات ، ولكن يقذفني في غلاف بدون مؤشر.

قد يكون من الجيد جدًا أنني الشخص الجاهل هنا (بالتأكيد هناك الكثير الذي لم أحصل عليه ، وقد شارك الكثير من الأشخاص ، لذلك أعتقد ذلك :)) ، أشعر فقط مثل هذا كله الشيء ليس تماما ... صحيح ...؟

في صحتك :)

تحرير: بالنظر إلى هذا السلوك ، هل هناك أي طريقة بالنسبة لي للتحقق من داخل اختبار Mocha إذا كان يتم تشغيله باستخدام --watch حتى أتمكن من التأكد من عدم الاتصال بـ process.exit() وكسر الأشياء؟

DanielSmedegaardBuus TL ؛ DR على الحل: ضع --exit في الملف mocha.opts . (عادةً ما يكون هذا هو الحل لأي شيء يجب تعيينه دائمًا عند تشغيل Mocha ، كنصيحة عامة.) توضيح أكثر تفصيلاً لما يدور حوله هذا التغيير: أدناه.

2640 يتعلق برفض الوعد ، وليس المقصود منه فعل أي شيء ولكن جعلها متوافقة مع الاستثناءات المتزامنة التي تم إلقاؤها من كود الاختبار غير المتزامن غير الوعد ، ولم يتم تنفيذه بعد

يتعلق الأمر باختبارات إعداد الموارد أو المستمعين أو العمل الجاري وعدم تنظيفه ، بغض النظر عما إذا كانت الوعود تستخدم في تنفيذها و / أو في الاختبار. فمثلا:

لدي اختبار لواجهة برمجة تطبيقات على أساس مآخذ الويب ، والتي تتضمن فتح وإغلاق الاتصالات. كانت واجهة برمجة التطبيقات هذه عربات التي تجرها الدواب ولم تكن تغلق الاتصالات بشكل صحيح ، ولكنها اجتازت اختباراتي لأن الاختبارات لم يكن لديها حقًا طريقة لتأكيد أن الاتصال الأساسي تم التعامل معه بشكل صحيح. (إذا كنت قد اختبرت الكود الخاص بي بشكل صارم ، كان بإمكاني التحقق من أنه يستخدم التبعية في ما اعتقدت خطأً --no-exit (من Mocha 3 ؛ الآن الافتراضي في Mocha 4) واكتشفت أنه إذا أجريت هذه الاختبارات ، فلن تغلق Node لأنني اتصال websocket لا يزال يستمع.

(صحيح أنه من المحتمل أن الخطأ يكمن في التبعية وليس في الكود الخاص بك ، ولكن حتى ذلك الحين ، يمكن أن يكون هناك قيمة في معرفة أنه قبل الشحن بإصدار معين من تلك التبعية - كما أشرنا أعلاه ، هذا هو أكثر قابلية للتطبيق على اختبارات التكامل في المقام الأول من اختبارات الوحدة ، ولكن من الناحية المثالية ، يحتوي المشروع على كليهما.)

هذا ليس ضروريًا دائمًا ، بالطبع - في بعض الحالات ، قد يُقصد من مورد من هذا النوع أن يبقى على قيد الحياة حتى تنتهي العملية ، أو قد يبقي Node على قيد الحياة على الرغم من عدم وجود أي تنظيف آخر للمورد مهم حقًا ، أو قد يكون جزءًا من مجموعة موارد تعيد استخدام الأعضاء الفرديين ولا تحتاج إلى تنظيف المجموعة ككل - في مثل هذه الحالات ، سيكون --exit صحيحًا . كان سبب تغيير السلوك الافتراضي هو زيادة وضوح مثل هذه المشكلات: من قبل ، ربما لن تعرف أبدًا تجربة --no-exit والتحقق من هذه الأنواع من الأخطاء ، والآن ستواجهها افتراضيًا ويمكن --exit إذا قررت أن السلوك صحيح (أو على الأقل لا يستحق القلق بشأنه).

هناك ، بالطبع ، مشكلة ما في "الإصلاح" والتي لا يكون

أنا آسف ، لكن هذا كان محبطًا للغاية. كنت أحاول فقط معرفة سبب عدم خروج المخا. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit روابط إلى why-is-node-running ، لذا فقد ذهبت الآن ، وحاولت استخدام هذه الوحدة ، ورأيت رسالة مشفرة "خطأ: لا يمكن العثور على الوحدة" داخلي / قائمة مرتبطة '... (تتبع المكدس) "، وبعد متابعة حفرة الأرانب في محاولة لمعرفة سبب عدم عمل - expose-internals ، انتهى بي الأمر في https://github.com/mochajs/mocha/ قضايا / 3045 للعثور على حل مفترض ، لكن why-is-node-running يخبرني أن هناك مقبض واحد معروف يبقيه مفتوحًا ، وعدد قليل من المقابض غير المعروفة ، لكنه لا يسرد أي شيء.

قد لا يكون هذا هو المكان المناسب لإثارة هذا الأمر ، ولكن لا ينبغي أن توصي مستندات mocha بالحلول التي تتطلب الكثير من البحث في googling ومشكلة الغوص للوصول إلى العمل . كنت أحاول إخراج الأشياء وإضافتها ، بسلوك غير متسق للغاية. من أجل المستخدمين في المستقبل وسلامة العقل:

package.json:

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

هذا أفضل ما يمكنني فعله.

jeffvandyke أنا أتفهم

كان لدي عدد من المواصفات التي كان لها سلوك غير متزامن غير مستقر. اعتمادًا على ترتيب تشغيل المواصفات الخاصة بي ، سيتم تسجيل أخطاء رفض الوعد غير المعلنة في وحدة التحكم ثم يتم تمريرها بعيدًا عن الأنظار بواسطة مئات الاختبارات الأخرى التي تم اجتيازها ، أو سيتم إغلاق مثيل العقدة قبل حدوث الرفض.

بعد إزالة --exit من mocha.opts ، فإن الوعود المرفوضة ستسجل الأخطاء بشكل موثوق ، وتبرز تلك الأخطاء.

أعلم ، الكثير من الألم المشترك :) يبدو سلوك Mocha الموثق صحيحًا بالنسبة لي ، ولكن على الرغم من أن اختباراتي الخمسة تبدو بسيطة بما يكفي ، فقط باستخدام node-fetch لاختبار API ، ما زلت غير متأكد من سبب عدم خروج mocha ، على الرغم من نجاحهم جميعًا (نعم ، يمكنهم الفشل أيضًا). يمكنني قضاء المزيد من الوقت في محاولة اكتشاف سبب عدم عمل why-is-node-running ، لكنني سئمت من التفكير في رموز الآخرين ، لذلك أعتقد أنني سأمنح نفسي استراحة في الوقت الحالي.

من المحتمل أن أستمر في اللعب بها ، وإذا كان بإمكاني الحصول على شيء قابل للتكرار ، فقد أفتح عددًا جديدًا ، بدون وعود.

سيوصي بمصحح أخطاء مفتش العقدة الجديد ... له آثار غير متزامنة جيدة.

ياي! تبين أن wtfnode أفضل بكثير في تسليط الضوء على هذا. اكتشفت أنه عند استخدام node-fetch ، يجب أن أتصل بـ result.text() أو .json() أو يظل الاتصال مفتوحًا. كشف تشغيل wtfnode ./node_modules/.bin/_mocha والضغط على Ctrl-C عن الاتصالات المفتوحة.

أعتقد أنه كان من الأسهل إذا أوصت المستندات بهذه الحزمة بدلاً من why-is-node-running .

اقتراح آخر: تعجبني حقًا فكرة andywer عن وجود نوع من التحذير إذا لم يخرج mocha. سيكون من الرائع أن تستخدم mocha wtfnode بطريقة ما لإدراج المقابض النشطة التي تحافظ على بقاء العقدة على قيد الحياة بعد مرور بعض الوقت.

أيا كان الشيء الصحيح الذي يجب أن يكون ، أعتقد أنه من القمامة التي كان عليّ أن أنظر إليها بعيدًا لمعرفة سبب عدم خروج الموكا. على أي حال ، لقد قدمت اقتراحاتي :)

اهلا ياجماعة،
وأعتقد أن هذه الميزة قد لا يزال لا يعمل بشكل صحيح، وهذا هو الأكثر الاختبار الأساسي ما كنت أفكر فيه والمخاوي لا يزال يفشل في الخروج من تلقاء نفسه. --no-exit هو خيار افتراضي ممتاز وأنا أؤيده جميعًا ، لكنني إما أفشل في فهم ما أفعله خطأ أو أن هناك شيئًا خاطئًا جوهريًا في mocha ويمنع إغلاق حتى أبسط الاختبارات.

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

الملخص: --exit يعمل ، --no-exit لا يغلق أي اختبار.

في حالتي ، أستخدم تطبيق Koa وأجري الاختبار باستخدام Mocha 4 + Supertest .

اضطررت إلى إغلاق الخادم مع done call بعد ملاحظات الإصدار "لتجنب الإيجابيات الكاذبة وتشجيع ممارسات الاختبار الأفضل".

قبل:

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

بعد:

const server = app.listen()

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

آمل أن يساعد ذلك.

أنا أفعل بعض التمهيد للموكا قبل كل اختبار. بدء تشغيل خادم HTTP صغير في نفس العملية.

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

أحب الفكرة الكامنة وراء هذه الميزة بالمناسبة .. إنها اختبار جيد لمعرفة ما إذا كان لديك أحداث متدلية.

evert ألا يعمل إغلاق الخادم في after ؟

هل هناك "بعد كل شيء" عالمي يتم تشغيله بعد انتهاء عمل الموكا؟ ربما فاتني ذلك! تعذر العثور عليه في المستندات.

نعم ، هناك ربط عالمي after .

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

شكرا لك! فاتني ذلك ، آسف: / لم أكن أعرف شروط ctrl-f لـ.

لم يعمل wtfnode حقًا بالنسبة لي. كل ما استطعت رؤيته هو أن بعض PID التي بدأها المخاوي كانت معلقة.

من ناحية أخرى، عملت جوهرboneskull: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745. شكرا لك!

wtfnode مقابل _mocha ، وليس mocha .

شكرًا على --exit . أصلحته لي.

أدخل هذا البرنامج النصي في package.json:
"نصوص": {
"اختبار": "mocha --exit"
}

جربت العلاجات المختلفة المذكورة في هذا الموضوع:

• لماذا هو عقدة تشغيل لا ينتج أي إخراج
• ينتج wtfnode الإخراج ولكن ليس كافياً لتحديد مكان إنشاء واصفات الملفات / المقابس / الخوادم / المؤقتات في الكود
• أخطاء أسلوب التصحيح async_hooks
• تؤدي إضافة –exit إلى mocha cmd line flag إلى الخروج

لذا تابع ProfJigsaw واستخدم –exit ، هذا ما أفعله. سيكون رائعًا إذا كان هناك تحسن من قبل mocha ، على الأقل طريقة لمعرفة مكان المشكلات وكيفية حلها.

هذا ما يفعله المصحح ، IMO. كيف يمكنك تصحيح البرامج النصية الخاصة بك إذا لم يتم الخروج منها مطلقًا؟

https://github.com/GoogleChromeLabs/ndb مشروع رائع.

خارج الموضوع: أحب هذه التذكرة ، فقط للحصول على معلومات حول أدوات استكشاف الأخطاء وإصلاحها التي تستمر في تقديمها! :)

borisovg تخيل كم ستكون هذه التذكرة رائعة إذا قدمت حلاً بالفعل! :)
boneskull هل توجد ميزة مصحح الأخطاء "list file descriptors / Sockets / Servers / Timer" التي لست على علم بها؟

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 db مفتوح ، فسيكون مفتوحًا. لماذا تفترض أنه خطأ؟

evert أعتقد أنك ربما أساءت تفسير ما كتبته

الحد الأدنى من الأمثلة رائع للتوضيح ، ومن المفيد حقًا رؤية مخرجات مماثلة لما تراه ، ولكن في الكود الحقيقي الذي تمت كتابته على مدار سنوات عديدة ، ليس من السهل العثور على هذه الاتصالات. من الجيد أن تعرف أن هناك اتصالات mongo لا تزال مفتوحة ، ولكن العثور عليها في الواقع ليس بالأمر السهل. لقد وجدت في النهاية بعض الاتصالات المفتوحة ، لكنها كانت أعمق بكثير في الكود من مستوى السطح حيث تم إغلاق جميع الاتصالات بشكل يمكن التحقق منه ، لم يساعد wtfnode في تحديد مكان وجودها فقط من خلال سرد مسار الوحدة النمس. لا يزال لدي البعض لتعقبه ، بناءً على رقم المنفذ فقط ، لكنني متفائل.

واجهت هذه المشكلة بالذات في كتابة دالة Serverless تتواصل مع Firebase. تبين أن المشرف SDK الخاص بهم يحتفظ بمقبض مفتوح إلى أجل غير مسمى. وبسبب هذا التغيير (واقتراح لاحقا لاستخدام wtfnode ، وكنت قادرا على تحديد هذه الحقيقة وإنقاذ نفسي من نصف طن من الصداع (والتكاليف) على الطريق.

في رأيي ، سيكون من المفيد جدًا تضمين نوع من المنطق "إذا كان معلقًا لمدة X طويلة وليس لديه أي إخراج يرمي بعض النص إلى stdout". لست متأكدًا من مدى جدوى ذلك أو مقدار النطاق الترددي المتاح لإنتاج مثل هذا التحسين ، لكنني أعتقد أن ذلك قد يساعد في التخفيف من بعض الإحباط الأولي من "wtf يجري مع mocha!"

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

إذا نسيت timers.restore(); ستتوقف العملية إلى الأبد.

بناءً على الوثائق pgilad المرسلة هنا ، هناك حل أكثر نظافة بالنسبة لي. كما تقول الوثيقة :

لتجنب الإيجابيات الكاذبة وتشجيع ممارسات الاختبار الأفضل ، لن تقتل Mocha نفسها تلقائيًا عبر process.exit () عندما تعتقد أنه يجب القيام بها قيد التشغيل.

حل أكثر وضوحًا سيكون إنشاء وظيفة 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);

هل هناك أي احتمال أن يتناغم أحد المطورين حول سبب تسبب إضافة هذا إلى Mocha السليم في إيذاء شخص ما (لأنه من الواضح أنه سيساعد الكثير من الأشخاص)؟

machineghost أحب السلوك الجديد لسببين:

1. لن تخرج أي مكتبة أخرى تقريبًا بعد أن "تنجز عملها". على سبيل المثال ، لن يؤدي إغلاق خادم Node TCP إلى تشغيل الخروج تلقائيًا. بهذه الطريقة ، تتفق مع المكتبات الأخرى.
2. إذا لم تخرج العقدة ، فهذا يعني أنه لا تزال هناك أحداث تنتظر حلها. ربما يكون من الأفضل محاولة تحسين التعليمات البرمجية الخاصة بك حتى يتم تنظيف الأشياء بعد كل اختبار. قد يشير أيضًا إلى وجود تسرب للذاكرة.

لذلك عندما واجهت هذا ، يكون هذا حافزًا لي لمحاولة تنظيف الكود الخاص بي حتى لا يحدث ذلك.

قد تكون وجهة نظرك حول هذا الأمر "أنا لا أكترث بشأن تسرب الذاكرة" ، أو "هذا لا يستحق الإصلاح في تطبيقي". إذا كنت في هذه الفئة ، فإن الأسهل هو إنشاء mocha.opts وإضافة --exit .

يبدو لي أن الأمر يتعلق بإحداث المزيد من الضوضاء ، وليس الإشارة: في الغالبية العظمى من الحالات ، لن يتحسن تطبيق أحد لأن Mocha معلق في النهاية.

إذا كان Mocha يتجه إلى الوضع الافتراضي ، فيبدو أنه يجب أن ينتهي بشكل افتراضي عند انتهاء الاختبارات (وجميع مكالمات 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 )؟

أعني ، إذا جعلت هذا الخيار ، فمن الناحية الواقعية ، كم مرة تعتقد أن الناس قد يجتازونه؟

ملاحظة: لقد صادفت هذا للتو: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection. إذا نظرت إلى الإجابة الثانية ، فإن هذا السلوك في Mocha تسبب بشكل مباشر في قيام مستخدم واحد على الأقل (ليس أنا ، وأقسم أنني لا أعرفهم: لقد وجدت هذا فقط عن طريق الحظ بعد إنشاء آخر مشاركة لي) لإضافة غير صحيحة رمز غير اختبار (هذه "الميزة" جعلتهم يعتقدون بشكل غير صحيح أنه يلزمهم استدعاء knex.destroy() في تطبيقهم).

نسخة موجزة:

شخص لطيف: ربما لا تحتاج عادةً إلى استدعاء knex.destroy () صراحة - وهذا يعني ضمنيًا من خلال التوثيق نفسه الذي يقول (التركيز لي):

شخص لطيف: اقتباسات مستندات

شخص مرتبك: إذا لم أتصل بـ knex.destroy () ، فسيتعطل البرنامج النصي الخاص بي. ثم ماذا يعني ذلك أننا لا نحتاج صراحة إلى استدعاء knex.destroy ()

شخص لطيف: آه ، لقد ذكرت فقط في مكان آخر أن هذا مخصص لـ Mocha. بالنسبة إلى استخدامات الخادم العادية ، لا تحتاج إلى هدم تجمع الاتصال - بالنسبة إلى Mocha ، قد ترغب في النظر في خطاف تمزيق عالمي ، راجع futurestud.io/tutorials/…

ولكن لكي نكون واضحين ، كان لدى هذا المستخدم بيئة عمل ، ولأن Mocha (بشكل أساسي) أخبرهم أن كودهم الجيد تمامًا كان خاطئًا ، فقد فقد من يعرف مقدار الوقت الذي يحاول فيه حل الخطأ الذي أنشأه من خلال تدمير اتصالاتهم. وهذا مجرد شخص سيئ الحظ فعل ذلك في الأماكن العامة ، والذي صادف أن رأيته.

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

أنا آسف ، لقد أخطأت في وجهة نظرك المتعبة على أنها سؤال صادق. يؤسفني الرد. ربما يمكن للمطورين قفل هذا الموضوع.

عمل لي "mocha --reporter mocha-allure-reporter ./tests/controllers --exit" . في الواقع ، يعد --exit حلاً جيدًا جدًا. أستخدم الإصدار 5.2.0 في مشروعي.

هل هناك طريقة للحصول على التأثير المكافئ لاستخدام علامة --exit عند استخدام mocha " برمجيًا ؟"

لا أرى خيارًا موثقًا للخروج / noexit ، ولا طريقة عامة لتمرير سلسلة العلم أثناء استخدام NodeJS 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/ " } وهو لا يعمل

كان لدي نفس المشكلة وأعتقد أنني لست الوحيد. كان علي أن أتحرك - الخروج في النهاية.
هذا لم ينجح:
غلاف اسطنبول ./node_modules/mocha/bin/_mocha --exit - test / .test.jsلقد عملني هذا:غلاف اسطنبول ./node_modules/mocha/bin/_mocha - test / .test.js --exit

exit لا يفعل شيئًا عند تشغيل Mocha برمجيًا ، fwiw. يتم إخراج العملية إجباريًا بواسطة غلاف CLI ، وليس Mocha-the-library.