Mocha: 退出全局

即使当您require('mocha') ，它只是在全球范围内丢弃废话，也会比当前情况更好。

我不认为这很愚蠢，但在所有方面都存在取舍。 我会对这样的事情感到满意：

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

没有人会使用它，但至少它将是一种更清洁的方式来实现我们目前拥有的东西。 每个人每次都必须设置一个样板，但是如果我们可以将其范围缩小到CLI样的API，那就可以了。 即使在ARGV中刚刚传递了lib / cli.js，但我仍然怀疑有人会使用它，您可以在没有CLI的情况下轻松使用它，但这说明没有人真正想超越某些极端情况。

@visionmedia看起来不错。 我之所以建议require("mocha/bdd")或类似的原因是，就现有的Mocha而言，实现起来非常容易，但是，可能更好。 （您可以设想使用它来一次或多次运行多个测试套件。嗯，这可能会因为process.on（'uncaughtException'）的使用而中断，但是您明白我的意思了。）

我可能会尝试这一天的拉取请求。

这是一个很好的例子，其中一些未来的JavaScript通过解构分配大有帮助。
https://developer.mozilla.org/zh-CN/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

并运行该测试吗？

@glenjamin是

尝试自己在nodespec上执行此操作后，问题并没有真正使各种功能可用，问题是弄清楚了如何/何时开始执行-我们仍然需要两遍定义/运行方法。

我想到的选择是：
1）让每个用户将可能要独立运行的每个文件的底部都添加类似mocha.exec（）的内容
2）等待核心添加诸如process.on（'exit'）之类的东西，但是当事件循环仍然可用时
3）假设每个文件只有一个顶级describe块，并在完成后开始执行

（1）可能是最好的，可能看起来像这样：

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

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

run();

当您确实需要在没有mocha包装程序的情况下运行时，这似乎并没有增加node ./node_modules/.bin/_mocha test/a-mocha-test.js的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二进制文件运行时已经提供了此功能，那么我同意对node进行相同的操作会很好。 会调查一下。 谢谢！

现在，该节点具有一个beforeExit挂钩，这似乎相当可行。

需要像

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

我感到不使用Mocha的人就是不能通过node运行测试文件的人，他们就是不喜欢Mocha的人，他们正在寻找借口！ 摩卡咖啡不一定适合所有人：微笑：

同样在这里。 我正在使用jspm和SystemJS ，无法在浏览器上运行的测试中使用import Mocha。

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

在浏览器中使用时无法使用。

@glenjamin只是需要发生。 Mocha应该具有核心的编程API。 一个不错的副作用是可节点测试。 它运行所在的环境将使用编程API，无论是浏览器，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可执行文件将继续使用全局变量； 那将永远不会改变。

我们可以（并且应该）争取的是能够通过node轻松运行Mocha测试而不会污染全局名称空间的能力。 这就是这个问题所在。

不幸的是，这是德克萨斯州大小的麻线球，没有人有时间或精力解开，这在这个问题的年龄上应该很明显……

mocha可执行文件将继续使用全局变量； 那将永远不会改变。

尽管我对摩卡咖啡的结构一无所知，但我可以断言，这种单一设计选择是问题的根源。

可能是这样！

我实际上看了一下代码，发现（或多或少）上次我尝试破解全局变量时做错了什么，考虑了如何获得可以用node test/someFile.js运行的测试文件。

• 避免全局
  
  
  
  • 即使在专业英语专业中，我们也无法打破使用全局变量的绝大多数Mocha用法。 团队所有人都可以辞掉日常工作，再也不需要睡觉，在事业上度过余下的时光，但实际上仍然没有足够的工时来处理无法想象的大量支持请求。 因此：这将永远是一个标志。
  
  
  • 目前，BDD和TDD接口是特殊情况：两者都将作为require("mocha").it等导出（并且没有其他接口）。 （注意：选择其他接口时不会中断的原因可能是Mocha有一个bug，在大多数情况下，即使选择了另一个接口，Mocha也会设置BDD接口。＃2207）我想离开这个。
  
  
  • 自定义（第三方）接口应该能够使用导出方案（只要它们使用发出的上下文对象而不是对global进行硬编码）。
  
  
  • 我们不可能让所有可能的接口都将其功能添加到Mocha （ require("mocha")导出内容）。
  
  
  • 如果我们修复了始终设置BDD接口的错误，那么还要继续在Mocha上导出BDD和TDD接口，将非常棘手。
  
  
  • 无论如何，您都不应该将Mocha的UI设置为TDD并使用BDD界面，反之亦然，除非您使用require("mocha/tddInterface").test或require("mocha/interface/bdd").it （不要与"mocha/lib/interfaces/<interface name>"混淆，实作）。
  
  
  • 如果可能，为了保持向后兼容性，我们可以保留Mocha上export-BDD和TDD的行为，直到出现严重错误为止。 我不希望当我们放弃它时，会有很多人抱怨，因为请求和使用它的人比大多数人更了解自己在做什么，反正也不完全满意（因为全球客户仍在）。
  
  
• 节点能力，即能够运行node test/someFile.js而不是mocha test/someFile.js
  
  
  
  • 尽管它没有全局变量那么普遍，但我认为我们无法承受破坏使用var Mocha = require("mocha"); var mocha = new Mocha()等（例如“程序化界面”）的人们的负担。 我们要么必须检测到该情况，然后避免以“可节点方式”运行Mocha，否则（对我们来说更方便，但需要用户选择加入）要求通过其他导入来访问节点功能，例如require("mocha/nodeable").it （ .describe等）。 特殊的导入而不是require("mocha")在，并且符合我的愿望（在避免使用globals部分中对此进行了说明和说明），不再需要导出Mocha对象上的接口由require("mocha")导出。
  
  
  • 为了能够node test/someFile.js ，仅仅someFile.js能够导入Mocha的界面是不够的：必须实例化Mocha，并且在所有测试完成之后，Mocha必须运行。 换句话说， require("mocha/nodeable")必须实例化Mocha并导出接口，然后...在测试文件运行之后，它必须运行Mocha。
  
  
  • 一种实现方法是在process.on("beforeExit"运行Mocha，前提是测试文件不会启动任何异步操作。
  
  
  • 另一种方法是在process.nextTick或setImmediate或setTimeout(..., 0 /* or some small number */)运行Mocha。
  
  
  • 即建立自己的东西与测试--delay和异步运行与run()将是一个问题。 不是因为不知道何时运行-更容易，而是run() -甚至不是因为不知道是否要运行--delay （请参阅下文，或提供require("mocha/nodeable/delayed") ），而是因为run()仅应按照当前设计在一个测试文件中调用。 可以说该设计已经很难使用，我们需要对其进行修复，以便无论如何都应在每个测试文件中调用run() ，在这种情况下，将其与“可节点测试”一起使用会很容易修复它。 否则...我不确定该怎么办。
  
  
  • 如果我们希望能够通过mocha而不是node调用这些测试文件（即使用此方法不会强制使用node ），那么require是什么
  
  
  • 如果我们要支持在通过Node运行或使用mocha.opts或允许可节点测试文件使用除Mocha的默认行为以外的任何行为时传递Mocha标志，则需要使CLI片段更具模块化。行为。
  
  
• 结合这两个想法的约束，我建议（并相信我可以实现） ：
  
  
  
  • 避免全局
  
  
  • 与其传递接口global对象来放置其功能，不如传递它们一个“选定的接口对象”。 （已编辑：必须在lib/mocha.js和browser-entry.js 。据我所知，该提案的所有与全局相关的部分都可以在Node和浏览器中使用。 ）
  
  
  • 之后，它将把所选接口对象的所有内容复制到global 。
  
  
  • localInterface选项（在CLI上为--local-interface ）将阻止Mocha从所选接口对象复制到global 。
  
  
  • 可初始化：最初，对于与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设置为在测试文件之后运行（除非使用delay ，否则大概使用setTimeout ，请参见上文delay ），然后导出该接口的选定接口对象，类似于require("mocha/interface/<specific interface>")
  
  
  • 如果支持CLI选项或mocha.opts ，则require("mocha/nodeable")将实例化Mocha，将Mocha设置为在测试文件之后运行（请参见上文），并执行与CLI相同的界面设置步骤，并导出选择的接口对象就像require("mocha/interface") 。
  
  
  • 如果我们希望可节点测试文件也可以mocha可用，则不需要mocha/nodeable和mocha/nodeable/<specific interface> ，我们可以在mocha/interface上搭载节点功能。 mocha/interface/<specific interface> 。
  
  

有什么想法吗？

实际上，经过进一步的思考，我基于以下理由反对使用node <test file>代替mocha <test file>来关闭这张票：

• 我不知道它提供的任何优势。
  
  
  
  • 一个可能的想法是，无论mocha.opts有什么glob，它都只运行一个测试文件。 简单的解决办法：在把水珠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的编程API将相同的代码放入假设的包"nodeable-mocha" 。
  
  
  
  • 我并不是说一开始就很容易实现，我是说我不知道​​由于不在Mocha之外而更难以实现。
  
  

如果我们发现任何比核心更容易实现的重大优势，我们可以随时重新开放。

但是，我也提议重新开放避免全局票，因为：

• 虽然优势不太可能相关（其他几个图书馆正在使用名为describe ， it等的全局变量？），但原则上是可能的（该问题的答案可能更大大于0，但很少）-从理论上讲，不将内容转储到全局名称空间中是正确的事情。
  
  
  
  • 此外，我的计划会将相同的行为扩展到正确编写为使用发出的“上下文”对象（Mocha当前始终使用全局对象）的第三方接口，而不是对全局对象进行硬编码。 尽管我们自己的接口似乎不太可能干扰其他库，但我们无法保证其他接口，因此我们也将使它们更容易执行正确的操作。
  
  
• 我的计划将清理当前行为中的许多相关边缘情况（例如，将其扩展到第三方接口，而且在Mocha中保持一致性，而不是对BDD和TDD接口进行特殊封装）。
• 在Mocha之外实现它的唯一简单方法是使用Mocha的编程API并对其进行猴子补丁处理，这也会留下一些前述的不一致和边缘情况。

因此，您建议Mocha提供一种使用mocha但在不会污染global的标志后面运行测试的方法吗？

摩卡咖啡的部分原因是摩卡咖啡，其成功的部分原因在于它不需要样板即可进口东西。 尽管围绕污染全局名称空间的教条仍然存在，但是对于开发人员而言，完全有充分理由这样做。

因此，您暗示Mocha提供了一种使用mocha运行测试的方法，但是在不会污染全局的标记后面？

对。

摩卡咖啡的部分原因是摩卡咖啡，其成功的部分原因在于它不需要样板即可进口东西。 尽管围绕污染全局名称空间的教条仍然存在，但是对于开发人员而言，完全有充分理由这样做。

我并不是说我普遍不同意，但是作为一种选择加入功能，我可以看到一些开发人员可能希望在哪里导入而不是全局变量（也许他们希望其模块命名局部变量context如果他们忘记了var ，那么也许他们想使用第三方接口，在这种情况下更可能发生这种冲突），现在我想出了正确的方法与Mocha相比，起来也更容易（实际上，如果我不被其他东西所吸引，我可能会在本周的分支中草稿草稿进行演示）。

（此外，我们已经在进行某种尝试，在全局上设置接口之后，将其复制到Mocha对象中，以便您可以require("mocha").it ，但是我们已经使用了该版本坦率地说，维护很奇怪，前后不一致，容易出错，甚至无法避免污染全局名称空间。如果我们要完全保留这种功能，我们可能会更正它而不是维护一个可疑的版本。

与IMO相比，这与IMO能够进行node <test file>的Mocha测试形成对比，据我所知，这没有任何优势，并且在Mocha内部或外部同样难以实现。

@stevenvachon
为什么const {describe, it} = require('mocha')对我不起作用？ 我只是不确定...

$ node -v
v8.4.0

@zapphyre，您仍然需要通过mocha程序而不是node来运行测试套件。

您不能使用node来运行多个源文件，因此您会陷入mocha困境。 我不知道没有自己的可执行文件的测试运行器/框架。

更新了问题标题，使其更加具体

另一个原因是：我想使用不同的JS运行时来运行测试，例如low.js （因为它是我们的平台之一，其他是node.js，浏览器和React Native）。 当我有一个导入mocha并运行测试的JS文件时，我可以执行此操作，而必须调用mocha来运行测试时，则无法执行该操作。

我的意思是，您已经为浏览器做到了。 在该平台上，我有导入“ mocha”的JS代码，然后使用mocha.run()从全局mocha对象运行测试。

在浏览器中

• 加载摩卡并获取全局mocha对象
• 运行mocha.setup({ui: 'bdd'});
• 使用SystemJS加载所有测试文件
• 然后我跑

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

就是这样。 当我在node.js中尝试相同操作时，使用require语句而不是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个小时）Wiki页面https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically，但这是用于运行测试的。

另一个原因是：我想使用不同的JS运行时来运行测试，例如low.js （因为它是我们的平台之一，其他是node.js，浏览器和React Native）。 当我有一个导入mocha并运行测试的JS文件时，我可以执行此操作，而必须调用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的要求）

当我们合并分支与汇总并设置编译器时，这可能会变得更容易。 拥有一个esm包和一个使用esm代码路径并增加全局泄漏的旧式包似乎是可行的。 我们只需要在新添加的代码路径和捆绑包中进行更改，就必须格外小心，这样我们就不会在浏览器和节点上同时中断或编码

使用全局变量和类型，这只会使摩卡成为传统。

顺便说一句，刚创建的@types/mocha没有全局变量： https :

希望他们（全球人士）将很快被正式移除。