Mocha: الانسحاب من الكرة الأرضية

حتى لو تخلصت للتو من هراءها في جميع أنحاء الفضاء العالمي عندما تكون require('mocha') ، فستكون أفضل من الوضع الحالي للأشياء.

لا أعتقد أنها سخيفة ولكن هناك مفاضلات مع كل شيء. سأكون سعيدًا بشيء مثل هذا:

var Mocha = require('mocha');
var mocha = new Mocha(options);
mocha.describe('blah blah', function....

لن يستخدمه أحد ولكن على الأقل سيكون طريقة أنظف لتنفيذ ما لدينا حاليًا. سيكون هناك _ton_ من النمذجة التي يجب على الجميع إعدادها في كل مرة ، ولكن إذا تمكنا من تضييقها إلى CLI-ish APIs ، فسيكون ذلك جيدًا. حتى لو كان هناك lib / cli.js تم تمريره للتو في ARGV ، لكنني ما زلت أشك في أن أي شخص سيستخدمه ، يمكنك استخدامه بدون CLI سهل بشكل معقول ، لكن هذا يوضح أنه لا أحد يريد حقًا تجاوز بعض الحالات المتطورة.

visionmedia الذي يبدو لطيفًا جدًا. السبب في أنني اقترحت require("mocha/bdd") أو ما شابه ذلك هو أنه سيكون من السهل جدًا تنفيذه من حيث Mocha الحالية ، ولكن نعم ، ربما يكون تطبيقك أفضل. (يمكنك تصور استخدامه لتشغيل مجموعات اختبار متعددة في وقت واحد أو شيء من هذا القبيل. حسنًا ، من المحتمل أن ينكسر هذا بسبب العملية. على استخدام ('uncaughtException') ، لكنك ترى ما أعنيه.)

قد أحاول طلب سحب لهذا اليوم.

هذا مثال رائع حيث يقطع القليل من JavaScript في المستقبل من خلال مهمة التدمير شوطًا طويلاً.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_٪ 28Merge_into_own_page.2Fsection٪ 29

var [describe,it,beforeEach,afterEach] = new require("mocha")(options);

فقط أتمنى أن يكون هناك دعم انسجام العقدة لهذا.

هي فكرة هذا أن يكون قادرا على القيام به

node test/a-mocha-test.js

وهل أجرت هذا الاختبار؟

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

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

كانت الخيارات التي توصلت إليها هي:
1) اجعل كل مستخدم يضيف شيئًا مثل mocha.exec () إلى أسفل كل ملف قد يرغب في تشغيله بشكل منفصل
2) انتظر حتى يضيف core شيئًا مثل process.on ("خروج") ، ولكن عندما تظل حلقة الحدث متاحة
3) افترض أن كل ملف يحتوي على كتلة وصف واحدة من المستوى الأعلى ، وابدأ التنفيذ عند انتهاء ذلك

(1) ربما يكون الأجمل ، والذي قد يبدو كالتالي:

var run = require('mocha/required');

describe('blah blah' , function() {
// ..
});

run();

لا يبدو أن هذا يضيف الكثير من عمل node ./node_modules/.bin/_mocha test/a-mocha-test.js عندما تحتاج حقًا إلى التشغيل بدون غلاف mocha .

أعتقد أن هذا لم يعد يتناسب مع كيفية استخدام الموكا حاليًا. نظرًا لأن هذا الموضوع كان غير نشط لأكثر من عام ، فأنا أغلقه في الوقت الحالي.

إذا كان أي شخص لا يزال مهتمًا بهذا ، فلا تتردد في التعليق أو اقتراح طلب سحب وسننظر :)

هل يمكن إعادة فتح هذا؟ ما زلت مهتمًا بها كثيرًا. كان عدم التمكن من إجراء اختبارات mocha node test.js أحد الأسباب الرئيسية التي دفعتني أنا وزملائي في Mapbox إلى الابتعاد عن المخاوي لاستخدامه مثل الشريط والنقر. أنا شخصياً أفضل التمسك بالموكا ولكني أجد أن حجة "قدرة العقدة" مقنعة إلى حد ما.

تحرير: تم تطوير وسيطة "قدرة العقدة" بواسطة tmcw هنا .

من أجل الوضوح ، فإن عدم وجود واجهة قادرة على require ليس هو الحاجز الأساسي هنا من منظور المستخدم. تم توثيق ما يلي بالفعل للعمل:

var describe = require('mocha').describe;
var before = require('mocha').before;
var it = require('mocha').it;

ويصبح أجمل مع ES6:

import { describe, before, it } from 'mocha';

تكمن المشكلة في حقيقة أن هذا لا يعمل إلا عند تشغيله عبر ثنائي mocha .

أوه ، شكرا للتوضيح. :) إذا قدمنا ​​هذه الإمكانية بالفعل عند تشغيلها باستخدام ثنائي mocha ، فأنا أوافق أنه سيكون من الجيد فعل الشيء نفسه مع العقدة. سوف ننظر في الأمر. شكر!

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

سوف تحتاج إلى شيء مثل

var { describe, it } = require('mocha/auto')

بلى. كما قال TJ ، فإن المشكلة هي حتى لو جعلنا كل شيء "قابلاً للعقدة" ، فقد يتطلب الأمر الكثير من النماذج المعيارية لتكون مفيدة.

ومع ذلك...

glenjamin شكرًا على beforeExit . أعتقد أنه يمكننا الاستفادة من هذا. ربما لا يزال الناس يشكون من أنه الكثير من "السحر" ...

لقد أضفت إثباتًا للمفهوم إلى 3cdd4a04c48193cceac6af7db72af06d380014a9

على أي حال ، سيحتاج إلى القليل من العمل ، لكن أعتقد أنه يمكننا بسهولة تعميمه على جميع الواجهات. لا يوجد دعم هنا لـ Growl أو mocha.opts أو أشياء أخرى ذات صلة بـ process مثل أكواد الخروج. يجب علينا استخراج بعض التعليمات البرمجية من bin/_mocha وإعادة استخدامها هنا. ثم يمكن أن يكون لدينا دعم الحجة كذلك. فمثلا:

$ node test/my-test.js --reporter=dot

إذا كان لدى أي شخص أي اقتراحات ، فليعلم

أعتقد أن استخراج بعض الأشياء في bin/_mocha في نوع من CLI سيكون معقولًا جدًا بغض النظر.

ما زلت غير متأكد من أن هذه إضافة مفيدة حقًا؟

هل هناك فرق عملي كبير بين أي مما يلي؟

node test/test.js
./node_modules/.bin/mocha test/test.js
PATH=./node_modules/.bin:$PATH mocha test/test.js
npm test -- test/test.js

أشعر أن الأشخاص الذين لا يستخدمون الموكا لأنهم لا يستطيعون تشغيل ملفات الاختبار عبر node هم مجرد أشخاص لا يحبون الموكا ، ويبحثون عن عذر! لا يجب أن تكون المخا للجميع: ابتسم:

نفسه هنا. أنا أستخدم jspm و SystemJS ولا يمكنني import Mocha في اختباراتي التي تعمل على المتصفح.

import { describe, before, it } from 'mocha';

لا يمكن استخدامها عند استخدامها في المتصفحات.

glenjamin إنه نوع من يحتاج فقط أن يحدث. يجب أن يكون لدى Mocha واجهة برمجة تطبيقات برمجية أساسية. من الآثار الجانبية الجيدة لذلك الاختبارات القادرة على العقدة. ستستهلك البيئة التي يتم تشغيلها فيها واجهة برمجة التطبيقات البرمجية ، سواء كان ذلك متصفحًا أو CLI أو أي شيء آخر تمامًا. Mocha.app ، أي شخص؟ :)

مهتم بهذه الميزة!

+1 لـ:
import { describe, before, it } from 'mocha';

لدينا حاليًا const {describe, it} = require('mocha') ، لكن هذا ليس ضروريًا لأن الكرات الأرضية موجودة بالفعل.

إذا كنا مهتمين بدعم المتصفح ، فيمكننا دائمًا إجراء const {describe, it} = window.mocha . علينا بالفعل القيام بذلك من أجل الشاي .

حسنًا ، أفترض const {describe, it} = window أيضًا.

هذا أمر أساسي جدًا لبنية mocha التي تصدر mocha

لا أعتقد أن mocha يجب أن تحدد أي مساحة عامة بخلاف مساحة اسم واحدة ، وربما للمتصفحات فقط.

سيستمر الملف القابل للتنفيذ mocha في استخدام globals ؛ من المحتمل ألا يتغير أبدًا.

ما يمكننا (وينبغي علينا) أن نطلق عليه هو القدرة على إجراء اختبارات mocha بسهولة عبر node دون تلويث مساحة الاسم العالمية. هذا ما يدور حوله هذا الموضوع.

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

سيستمر الملف القابل للتنفيذ mocha في استخدام globals ؛ من المحتمل ألا يتغير أبدًا.

على الرغم من أنني لا أعرف شيئًا عن كيفية تنظيم المخاوي ، إلا أنني أستطيع أن أؤكد أن اختيار التصميم الفردي هذا هو مصدر المشكلة.

من المحتمل ذلك!

لقد ألقيت في الواقع نظرة ثانية على الكود ، واكتشفت (أكثر أو أقل) ما الذي فعلته بشكل خاطئ في المرة الأخيرة التي حاولت فيها الاختراق حول امتلاك الكرة الأرضية ، وفكرت فيما قد يتطلبه الأمر للحصول على ملفات اختبار قابلة للتشغيل node test/someFile.js ، وأعتقد أنني أعرف كيفية القيام بكليهما - مع التحذير من أن القيام بذلك دون مضاعفة عدد حالات الحافة ثلاث مرات من المحتمل أن يتطلب كسر بعض حالات الحافة الحالية. بمزيد من التفصيل ، أفكاري في التصميم هي:

• تجنب الكرة الأرضية
  
  
  
  • حتى في تخصص semver ، لا يمكننا كسر الغالبية العظمى من استخدام Mocha الذي يستخدم الكرة الأرضية. كان بإمكان الفريق جميعًا ترك وظائفهم اليومية ، وعدم النوم مرة أخرى ، وقضاء بقية حياتهم المهنية عليها ، ولا يزال لديهم حرفيًا ساعات عمل كافية للتعامل مع الطوفان الذي لا يمكن تصوره من طلبات الدعم التي قد تترتب على ذلك. لذلك: سيكون هذا وراء العلم إلى الأبد .
  
  
  • حاليًا ، واجهات BDD و TDD ذات غلاف خاص: سيتم تصدير كلاهما (ولا توجد واجهات أخرى) كـ require("mocha").it et al. (ملاحظة: قد يكون السبب في عدم انقطاع هذا عند تحديد واجهات أخرى هو أن Mocha بها خطأ حيث في معظم الظروف ستقوم بإعداد واجهة BDD حتى إذا تم تحديد أخرى. # 2207) أريد الابتعاد عن هذا.
  
  
  • يجب أن تكون الواجهات المخصصة (الطرف الثالث) قادرة على العمل مع نظام التصدير (طالما أنها تستخدم كائن السياق المنبعث بدلاً من الترميز الثابت global ).
  
  
  • لا يمكننا إضافة وظائف كل واجهة ممكنة إلى Mocha (ما يصدره require("mocha") ).
  
  
  • إذا أصلحنا الخطأ حيث يتم دائمًا إعداد واجهة BDD ، فسيكون من الصعب أيضًا الاستمرار في تصدير واجهات BDD و TDD على Mocha يتم اختيار واجهة أخرى.
  
  
  • لا يجب أن تضبط واجهة مستخدم Mocha على TDD وتستخدم واجهة BDD أو العكس على أي حال ، إلا إذا كنت تفعل require("mocha/tddInterface").test أو require("mocha/interface/bdd").it (لا يجب الخلط بينه وبين "mocha/lib/interfaces/<interface name>" حيث عمليات التنفيذ).
  
  
  • ربما يمكننا الاحتفاظ بسلوك التصدير BDD و TDD على موكا إن أمكن من أجل التوافق مع الإصدارات السابقة حتى تخصص semver. لا أتوقع أن يشتكي الكثير من الناس عندما نتخلى عنها نظرًا لأن الأشخاص الذين طلبوها ويستخدمونها يعرفون المزيد عما يفعلونه أكثر من غيرهم وغير راضين تمامًا عنه على أي حال (منذ الكرات الأرضية لا تزال هناك).
  
  
• قدرة العقدة ، أي القدرة على تشغيل node test/someFile.js بدلاً من mocha test/someFile.js
  
  
  
  • في حين أنها أقل انتشارًا من الكرة الأرضية ، لا أعتقد أننا نستطيع تحطيم الأشخاص الذين يستخدمون var Mocha = require("mocha"); var mocha = new Mocha() وما إلى ذلك (أي "الواجهة البرمجية"). سيتعين علينا إما اكتشاف ذلك وتجنب تشغيل Mocha "طريقة العقدة" وإلا (أسهل بالنسبة لنا ، ولكنها تتطلب الاشتراك من المستخدمين) تتطلب إمكانية الوصول إلى قدرة العقدة من خلال استيراد مختلف ، على سبيل المثال require("mocha/nodeable").it ( .describe إلخ). A استيراد خاص بدلا من حمل مركبة على require("mocha") سوف يكون من الأسهل لتنفيذ بأمان، وسوف تناسب مع رغبتي (وصفها وتبريرها في قسم غلوبالس تجنب) للابتعاد عن تصدير واجهات على Mocha الكائن تم تصديره بواسطة require("mocha") .
  
  
  • لتكون قادرًا على node test/someFile.js ، لا يكفي أن تتمكن someFile.js من استيراد واجهة Mocha: يجب إنشاء مثيل Mocha ، وبعد الانتهاء من الاختبارات ، يجب تشغيل Mocha. بمعنى آخر ، يجب أن يقوم require("mocha/nodeable") بإنشاء Mocha بالإضافة إلى تصدير الواجهة ، وبعد ذلك ... بعد تشغيل ملف الاختبار ، يجب تشغيل Mocha.
  
  
  • تتمثل إحدى طرق القيام بذلك في تشغيل Mocha في process.on("beforeExit" ، بشرط ألا يبدأ ملف الاختبار بأي إجراءات غير متزامنة.
  
  
  • هناك طريقة أخرى للقيام بذلك وهي تشغيل Mocha في process.nextTick أو setImmediate أو setTimeout(..., 0 /* or some small number */) .
  
  
  • قد تكون الاختبارات التي تقوم بإعداد عناصرها باستخدام --delay والتي تعمل بشكل غير متزامن مع run() مشكلة. ليس من أجل معرفة وقت التشغيل - هذا أسهل ، هناك run() - ولا حتى لمعرفة ما إذا كنت تريد --delay (انظر أدناه ، أو تقديم require("mocha/nodeable/delayed") ) ، ولكن بدلاً من ذلك run() المفترض أن يتم استدعاء run() في كل ملف اختبار على أي حال ، وفي هذه الحالة سيكون استخدامه مع اختبارات "قابلية العقدة" أمرًا سهلاً بعد تحديد ذلك. وإلا ... لست متأكدًا مما يجب فعله.
  
  
  • إذا أردنا أن نكون قادرين على السماح باستدعاء ملفات الاختبار هذه من خلال mocha بدلاً من node (أي أن استخدام هذا لا يفرض استخدام node ) ، إذن مهما كان require d يجب أن يكتشف وقت استخدام CLI وليس إنشاء Mocha بعد ذلك. سيكون هذا أسهل من اكتشاف وقت استخدام واجهة برمجة التطبيقات البرمجية - يمكن لـ CLI تعيين بعض الحالات العامة التي ستتحقق منها هذه الوحدات ، أو يمكن لهذه الوحدات التحقق مما إذا كان CLI هو الملف الذي قامت Node بتشغيله.
  
  
  • سنحتاج إلى جعل قطع CLI أكثر نمطية إذا أردنا دعم تمرير أعلام Mocha عند المرور عبر Node ، أو استخدام mocha.opts ، أو أي شيء من شأنه أن يسمح لملفات الاختبار القادرة على العقدة باستخدام سلوك آخر غير Mocha الافتراضي سلوك.
  
  
• بدمج قيود هاتين الفكرتين ، أقترح (وأعتقد أنني أستطيع التنفيذ) :
  
  
  
  • تجنب الكرة الأرضية
  
  
  • بدلاً من تمرير الكائن global للواجهات لوضع وظائفهم عليها ، فإنه سيمرر لهم "كائن واجهة محدد". (تم التعديل للإضافة: يجب أن يتم ذلك في كل من lib/mocha.js و browser-entry.js . بقدر ما أعلم ، فإن جميع الأجزاء ذات الصلة بالعالم من الاقتراح قابلة للتنفيذ في كل من Node والمستعرض. )
  
  
  • بعد ذلك ، سيتم نسخ جميع محتويات كائن الواجهة المحدد إلى global .
  
  
  • خيار localInterface ( --local-interface على CLI) سيوقف Mocha من النسخ من كائن الواجهة المحدد إلى global .
  
  
  • DEBATABLE: مبدئيًا ، للتوافق مع الإصدارات السابقة مع require("mocha").it Mocha ، ستقوم بنسخ وظائف TDD / BDD من كائن الواجهة المحدد إلى Mocha أيضًا ، ولكن هذا سيتم إهماله / إزالته لاحقًا.
    
    
    
    
    
    • (ملاحظة: إذا أوقفنا إعداد BDD عندما لا يتم تحديده ، فقد نضطر إلى القيام بمزيد من المعالجة الخاصة هنا لإعداد BDD على كائن واجهة محدد وهمي يمكن نسخها منه - حالة جيدة للإفلات السلوك تمامًا ، يصبح الأمر أكثر تعقيدًا كلما زادت الأشياء الأخرى التي نقوم بإصلاحها / تحسينها بينما لا نزال نحاول دعم ذلك.)
    
    
    
  
  
  • سيصدر require("mocha/interface") كائن الواجهة المحدد.
  
  
  • سيقوم require("mocha/interface/<specific interface>") باستدعاء الواجهة المحددة مع عنصر واجهة جديد محدد سيتم تصديره لاحقًا.
  
  
  • تم التعديل للإضافة: require("mocha/interface") سيكون أيضًا خاصية على الكائن mocha في المتصفح ، mocha.interface ، لدعم استخدام المتصفح بدون نظام وحدة.
  
  
  • قدرة العقدة
  
  
  • سيقوم require("mocha/nodeable/<specific interface>") بإنشاء مثيل Mocha ، وإعداد Mocha للتشغيل بعد ملف الاختبار (باستخدام setTimeout ما لم يتم استخدام delay ، انظر أعلاه حول re. delay ) و تصدير عنصر واجهة محدد لهذه الواجهة يشبه إلى حد كبير require("mocha/interface/<specific interface>")
  
  
  • إذا كانت خيارات CLI أو mocha.opts مدعومة ، فسيقوم require("mocha/nodeable") بإنشاء مثيل Mocha ، وإعداد Mocha للتشغيل بعد ملف الاختبار (انظر أعلاه) ، وتنفيذ خطوات إعداد الواجهة نفسها مثل CLI ، وتصدير كائن الواجهة المحدد مثل require("mocha/interface") .
  
  
  • إذا أردنا أن تكون ملفات الاختبار القادرة على العقدة أيضًا mocha -able ثم mocha/nodeable و mocha/nodeable/<specific interface> ليست ضرورية ، يمكننا استعادة قدرة العقدة على mocha/interface & mocha/interface/<specific interface> .
  
  

أفكار؟

في الواقع ، بناءً على مزيد من التفكير ، أقترح إغلاق هذه التذكرة ، بناءً على الأساس المنطقي التالي ضد استخدام node <test file> بدلاً من mocha <test file> :

• لست على علم بأي مزايا يقدمها.
  
  
  
  • إحدى الأفكار المحتملة هي أنه يقوم بتشغيل ملف اختبار واحد فقط بغض النظر عن الكرات الأرضية الموجودة في mocha.opts . حل بسيط: ضع globs في البرنامج النصي test في package.json بدلاً من ذلك: npm test سيتم تشغيلها جميعًا و mocha ( node_modules/.bin/mocha ، npx mocha ) سيتم تشغيل ملف (ملفات) الاختبار المحدد فقط. (الملفات أو الكرات الأرضية التي يجب تشغيلها لأي تشغيل اختباري بغض النظر عن عدد ملفات الاختبار التي يتم تشغيلها يجب أن تستمر في mocha.opts .)
  
  
  • فكرة أخرى محتملة هي أنه يسمح بتجاوز mocha.opts تمامًا. يجب أن يكون هذا ممكنًا الآن باستخدام mocha --opts /dev/null (أو على Windows mocha --opts nul ). إذا لم يكن الأمر كذلك لسبب ما ، فسيكون من الأسهل تنفيذ علامة CLI لتخطي معالجة mocha.opts .
  
  
• يمكن تنفيذه خارج المخا ؛ بدلاً من "mocha/nodeable" ، فقط ضع نفس الكود باستخدام واجهة برمجة تطبيقات Mocha البرمجية في حزمة افتراضية "nodeable-mocha" .
  
  
  
  • أنا لا أقول أنه سيكون من السهل تنفيذه في المقام الأول ، فأنا أقول إنني لست على علم بأي طريقة قد يكون من الصعب تنفيذها بسبب التواجد خارج المخا.
  
  

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

ومع ذلك ، أقترح أيضًا إعادة فتح تذكرة تجنب الكرة الأرضية ، للأسباب التالية:

• على الرغم من أنه من غير المحتمل أن تكون المزايا ذات صلة (كم عدد المكتبات الأخرى التي تستخدم الكرات الأرضية المسماة describe ، it وما إلى ذلك؟) ، فهي ممكنة من حيث المبدأ (يمكن أن تكون الإجابة على هذا السؤال أكبر من 0 ، على الرغم من قلة) - عدم إلقاء الأشياء في مساحة الاسم العالمية ، من الناحية النظرية ، هو الشيء الصحيح الذي يجب القيام به.
  
  
  
  • علاوة على ذلك ، ستمتد خطتي نفس السلوك إلى واجهات الطرف الثالث التي تمت كتابتها بشكل صحيح لاستخدام كائن "السياق" المنبعث (والذي يستخدم Mocha حاليًا الكائن العام دائمًا) بدلاً من تشفير الكائن العام ؛ بينما يبدو من غير المحتمل أن تتداخل واجهاتنا الخاصة مع المكتبات الأخرى ، لا يمكننا تقديم أي ضمانات حول الواجهات الأخرى ، لذلك سنجعل من السهل عليهم القيام بالشيء الصحيح أيضًا.
  
  
• ستقوم خطتي بتنظيف الكثير من حالات الحافة ذات الصلة في السلوك الحالي (على سبيل المثال توسيعها إلى واجهات الطرف الثالث ، ولكن أيضًا الاتساق في Mocha بدلاً من الغلاف الخاص لواجهات BDD و TDD).
• الطريقة سهلة فقط لتنفيذه خارج موكا هو استخدام API البرنامجي وقرد التصحيح انها موكا، وهذا من شأنه أن يترك بعض التناقضات المذكورة أعلاه والحالات حافة جدا.

لذا فأنت تقترح بدلاً من ذلك أن توفر Mocha طريقة لإجراء الاختبارات باستخدام mocha ولكن خلف علامة لن تلوث global ؟

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

لذلك أنت تقترح بدلاً من ذلك أن يوفر Mocha طريقة لإجراء الاختبارات باستخدام الموكا ولكن خلف علم لا يلوث العالم؟

نعم.

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

لا أقول إنني لا أوافق بشكل عام ، ولكن كميزة اشتراك ، يمكنني معرفة المكان الذي قد يرغب فيه بعض المطورين في الاستيراد بدلاً من الكرة الأرضية (ربما يريدون وحدتهم تسمية متغير محلي context دون الإشارة بطريق الخطأ إلى العالم إذا نسوا var ، فربما يرغبون في استخدام واجهة جهة خارجية حيث يكون هذا النوع من الاصطدام أكثر احتمالًا) ، والآن بعد أن اكتشفت كيفية القيام بذلك بشكل صحيح من الأسهل أيضًا القيام به في Mocha بدلاً من استخدامه كإضافة من نوع ما (في الواقع ، إذا لم أتورط في شيء آخر ، فمن المحتمل أن أقوم برمي مسودة تقريبية في أحد الفروع هذا الأسبوع للتوضيح).

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

هذا هو IMO على عكس القدرة على node <test file> لاختبارات Mocha ، والتي على حد علمي ليس لها أي ميزة وسيكون من الصعب تنفيذها داخل Mocha أو خارجها.

تضمين التغريدة
كيف يحدث أن const {describe, it} = require('mocha') لا يعمل معي؟ لقد حصلت للتو على ملفات غير محددة ...

$ node -v
v8.4.0

zapphyre ، ما زلت بحاجة إلى تشغيل مجموعة الاختبار عبر برنامج mocha ، وليس عبر node .

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

تم تحديث عنوان المشكلة ليكون أكثر تحديدًا

سبب آخر لهذا: أرغب في إجراء اختبارات باستخدام وقت تشغيل JS مختلف ، على سبيل المثال low.js (لأنه أحد منصاتنا ، والبعض الآخر هو node.js والمتصفح - و React Native). يمكنني القيام بذلك عندما يكون لدي ملف JS يستورد mocha ويدير الاختبارات ، لا يمكنني القيام بذلك عندما يتعين علي الاتصال بـ mocha لإجراء الاختبارات.

أعني ، لقد قمت بذلك بالفعل للمتصفح. على هذا النظام الأساسي ، لدي كود JS الذي يستورد "mocha" ثم يجري الاختبارات من كائن mocha عالمي باستخدام mocha.run() .

في المتصفح أنا

• قم بتحميل mocha واحصل على كائن mocha عالمي
• قم بتشغيل mocha.setup({ui: 'bdd'});
• قم بتحميل جميع ملفات الاختبار باستخدام SystemJS
• ثم أركض

      mocha.checkLeaks();
      mocha.globals([]);
      mocha.run();

وهذا كل شيء. عندما أحاول الشيء نفسه في node.js ، باستخدام عبارة request بدلاً من SystemJS لتحميل ملف اختبار ، أحصل على (باستخدام mocha 5.2.0)

> mocha.run();
TypeError: Cannot read property 'search' of undefined
    at Mocha.mocha.run (/home/mha/one/node_modules/mocha/mocha.js:149:54)

تحرير: حاولت https://github.com/mochajs/mocha/wiki/Using-Mocha-programmatically و mocha.addFile بدلاً من مجرد تحميله ، نفس النتيجة.

هل يوجد حاليا أي طريقة لاستيراد وصف / ذلك؟

يوجد جديدة (اعتبارا من الآن 20 ساعة القديمة) صفحة ويكي https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically ولكن هذا هو لتشغيل الاختبارات.

سبب آخر لهذا: أرغب في إجراء اختبارات باستخدام وقت تشغيل JS مختلف ، على سبيل المثال low.js (لأنه أحد منصاتنا ، والبعض الآخر هو node.js والمتصفح - و React Native). يمكنني القيام بذلك عندما يكون لدي ملف JS يستورد mocha ويدير الاختبارات ، لا يمكنني القيام بذلك عندما يتعين علي الاتصال بـ mocha لإجراء الاختبارات.

إذا كان وقت التشغيل البديل يحتوي على ملف تنفيذي يشبه العقدة (وهو ما أعتقد أن low.js يفعله؟) ، فيمكنك القيام بذلك alternative-executable ./node_modules/.bin/_mocha ، ويجب أن يعمل ذلك

لا أعرف عداء / إطار عمل لا يحتوي على ملف تنفيذي خاص به.

https://github.com/tapjs/node-tap/#tutti -i-gusti-sono-gusti

الآن بعد أن تم حل https://github.com/mochajs/mocha/issues/3006 ، سيكون من الجيد الحصول على نفس عمليات التصدير المسماة في المتصفح.

حاليا ، ما يلي يعمل:

<script type="module">
  import './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

لكن ما يلي ليس:

<script type="module">
  import { mocha } from './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

(حسب طلب https://github.com/mochajs/mocha/issues/956#issuecomment-167453800)

قد يصبح هذا أسهل عندما ندمج فرعنا مع Roll-up ونقوم بإعداد transpilers. يبدو أنه من الممكن أن يكون لديك حزمة esm وحزمة قديمة تستهلك مسارات كود esm وتضيف التسريبات العالمية. سيتعين علينا توخي الحذر الشديد لإجراء تغييرات فقط في مسارات وحزم الكود المضافة حديثًا حتى لا نفصل أو نبرمج في المستعرضات والعقد

مع vars والكتابات العالمية ، هذا يجعل الأمر مجرد إرث موكا.

راجع للشغل للتو إنشاء @types/mocha بدون الكرة الأرضية: https://github.com/whitecolor/mocha-types

آمل أن تتم إزالتها رسميًا قريبًا.