这是一个常见的建议，即Mocha 测试用例不应共享状态。鉴于 Mochas 测试用例执行的强烈顺序性，我真的不理解这个建议。还有更多——我认为这很可疑。
如果测试用例（即使是异步测试用例）严格地一个接一个地执行，则不存在时间竞争问题或其他不可预测的执行顺序的风险。
让我们看一下这个 Mocha 结构：
describe
describe
it1
it2 // async
it3
describe
it4
it5
describe
describe
it6 // async
it7 // async
it8
describe
it9
it10
测试用例将始终以清晰的顺序执行，it1，it2，... it10，独立于它们是同步还是异步，甚至独立于描述的层次结构。以下结构将产生完全相同的输出：
describe
it1
it2 // async
it3
it4
it5
it6 // async
it7 // async
it8
it9
it10
在单个describe()中的测试用例之间共享数据可以使测试用例之间的通信变得更加容易和舒适，以便：
- 重用测试代码并避免在每个（或
其中一些）测试用例。钩子在这里很方便，但有时却很方便
预期的控制比他们提供的更多
- 减少测试执行时间 - 可以节省大量时间，避免太多除了满足有关无状态性的建议之外什么也不做的钩子。
支持在测试用例之间使用共享数据的另一个事实是 Mocha 代码的这种简单而漂亮的结构。不同级别的describe()允许对最终共享数据进行简单、清晰的范围管理。
我看到的唯一负面影响是，当“全局变量”被“滥用”时，代码会变得更难理解、遵循和维护。无论如何，通过严格的编码，没有什么是无法避免的。
这里有什么我不知道的吗？
It is possible使用 Mocha 运行非无状态且相互依赖的测试。这不是摩卡的样子designed为了。归根结底，如果您想在测试之间强加依赖关系，当然可以。但它也有一些警告。
针对错误的事情进行优化
您引用了在测试之间共享状态的优势：
减少测试执行时间
Sure. 在其他条件相同的情况下，我们宁愿有一个运行时间更少的测试套件。在大型测试套件上，不重置测试之间的状态可能会节省大量时间运行整个套件时。然而，事实是“其他一切”并不相同：
运行整个套件应该通过一个自动化流程来完成，该流程报告哪些内容通过了，哪些内容失败了。换句话说，不应该有人坐在那里waiting使整个套件得以完成。
当出现故障或正在实施新测试时，开发人员将只想运行失败的测试或新测试，而不是整个套件。如果套件的设计使得测试 1 到 N-1 必须在测试 N 运行之前运行，那么开发人员等待获得他真正关心的测试结果的时间就会更长。所以他可以坐在那里以 X 美元/分钟的速度摆弄他的拇指。 “多任务”并不是答案，因为事实证明，切换任务会产生认知成本。 （“好的，测试完成了……等等，问题又出在哪里？”）
测试选择
您可以使用--grep选择特定的测试。这是非常有用在大型测试套件上，以避免浪费时间来运行您不关心的测试。因此，我们假设您的测试标题是it1, ... it10你用--grep it7。由于 Mocha 将所有测试相互独立，因此它只会运行任何测试before and beforeEach钩子适用于it7并运行测试（然后运行任何after and afterEach钩子适用于它）。它不会运行it1 to it6跑步前it7。为了让它运行这些测试，你必须制作一个--grep涵盖所有必要的测试，这当然总是possible做但不愉快。
在浏览器中运行 Mocha 时获得的 HTML 界面中，如果您希望 Mocha 只运行某个测试，则可以单击该测试。同样，如果您想要修复单个失败的测试，这将非常有用。如果失败的测试依赖于在其之前运行的一堆测试，则根本没有与此简单单击等效的操作。
测试订单
一般来说，如果您的测试必须按特定顺序运行，则必须小心确保拆分在多个文件中的测试将按测试运行所需的顺序加载。
例如，它将是possible使用全局结构在不同文件中存储的测试之间共享状态。但是，当测试位于不同的文件中时（其中一个文件不not require另一个），Mocha 处理文件的顺序完全取决于读取包含文件的目录时文件系统列出文件的顺序。有一个--sort适合那些想要基于字典排序的可预测顺序的人的选项。如果你想强加你自己的任意顺序，那么我想你必须命名你的文件01foo.js, 02bar.js, etc.
无论是使用 Node.js 运行 Mocha 还是在浏览器中运行 Mocha，都是如此。我有一些套件，其中测试文件是用 RequireJS 加载的。请求模块 A、B、C 不能保证它们会按照 A、B、C 的顺序加载，除非声明 C 依赖于 B（也可能是 A）并且 B 依赖于 A。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
