Node.js断言库与其他断言库

Question

根据node.js断言库文档:

该模块供Node.js内部使用,但可以通过require('assert')在应用程序代码中使用.但是,assert不是测试框架,并不打算用作通用断言库.

我在看Chai作为替代断言库(没有BDD API,只有断言API),最后我看到断言功能非常相似.

为什么Chai的断言库是一个更好的断言库？它完成了除node.js之外的所有工作(除了在可用的断言方面更加丰富,但这只是语法糖涂层).即使是简单的事情,例如执行的assert总数也不可用.

我错过了什么吗？

Answer 1

更新(2017年4月):Node.js不再警告人们不要使用,assert所以下面的答案现在已经过时了.但是,留下它的历史兴趣.

这是我在Node.js问题跟踪器上发布的一个非常相似的问题的答案.

https://github.com/nodejs/node/issues/4532和其他问题暗示了文档建议不要使用assert单元测试的原因:有边缘案例错误(或至少肯定是惊喜)和缺少的功能.

更多上下文:了解我们现在所知道的,如果我们再次设计/构建Node.js核心,那么assert模块将不存在于Node.js中,或者包含更少的函数 - 很可能只是assert()(这是目前是别名assert.ok()).

至少从我的角度来看,其原因是:

• 所有正在完成的工作assert都可以在用户区轻松完成
• 除了完善可在用户区完成的单元测试模块之外,核心工作更好地用于其他地方

还有其他人可能选择在这里添加的附加上下文(例如为什么,在所有条件相同的情况下,我们倾向于保持核心较小并在用户区域中进行操作).但这就是所谓的30,000英尺的视野.

既然assert已经在Node.js中存在了很长时间并且很多生态系统都依赖于它,那么我们不太可能(至少在当前时间我能说的最好)去除assert.throws()和朋友.它会打破太多东西.但是我们可以阻止人们使用assert和鼓励他们使用由深切关注他们并积极修复边缘案例错误的人维护的用户空间模块,并在有意义的时候添加很酷的新功能.这就是全部.

是的,如果您使用简单的案例进行简单的断言,assert可能会满足您的需求.但如果你长大了assert,你会变得更好chai或者更好.所以我们鼓励人们从那里开始.对他们(通常)更好,对我们(通常)更好.

我希望这有用并回答你的问题.

Answer 2

我想既然没人给我任何良好的反馈,我会尝试用Node.js的两个断言和柴氏断言工作一段时间后,提供有关我原来的问题做了解释.

最后的答案是功能方面它们是相同的.chai的断言存在的唯一原因是,如果你阅读代码,你可以更好地理解测试,但就是这样.

例如,使用Node.js测试空值:

断言(foo === null);

并使用柴:

assert.isNull(FOO);

它们是完全等价的,并坚持node.js断言限制你的依赖列表.

Answer 3

免责声明：我是assertthat模块的作者，我将在这个答案中引用该模块。

基本上，您可以使用 Node 自己的assert模块实现所有其他模块可以实现的功能，例如Should.js、expect.js或assertthat。它们的主要区别在于表达意图的方式。

从语义上来说，以下几行代码都是等效的：

assert.areEqual(foo, bar);
foo.should.be.equal(bar);
expect(foo).to.be(bar);
assert.that(foo).is.EqualTo(bar);

从语法上看，有两个主要区别：

首先，该should语法仅在foo不等于nullor时才有效undefined，因此它不如其他语法。其次，可读性存在差异：虽然assert.that(...)读起来像自然语言，但其他语言却不然。

毕竟，Chai 只是一些断言模块的包装，以使事情变得更容易。

因此，长话短说：不，没有技术原因说明为什么要选择其中一种而不是另一种，但可读性和null兼容性可能是原因。

我希望这有帮助 ：-）

PS：当然，在内部，它们的实现方式可能不同，因此可能存在一些微妙的事情，例如如何检查相等性。正如免责声明中所说，我是assertthat的作者，所以我可能有偏见，但在过去的几年里，我不时遇到assertthat比其他方法更可靠的情况，但正如所说，我可能是有偏见。