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

时间:2016-04-05 18:18:58

标签: javascript node.js unit-testing assert

根据node.js断言库documentation

  

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

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

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

我错过了什么吗?

4 个答案:

答案 0 :(得分:13)

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

此处the answer I posted to a very similar question on the Node.js issue tracker

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

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

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

  • assert中完成的所有内容都可以在userland中轻松完成
  • 核心工作最好花在其他地方,而不是完善可在用户区完成的单元测试模块

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

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

是的,如果您使用简单的案例进行简单的断言,assert可能会满足您的需求。但是,如果你长大了assert,那么assert或其他什么都会让你感觉更好。所以我们鼓励人们从那里开始。对他们(通常)更好,对我们(通常)更好。

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

答案 1 :(得分:6)

我猜是因为没有人给我任何好的反馈,在尝试使用node.js断言和chai的断言之后,我会尝试对原始问题提供一些启示。

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

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

  

断言(foo === null);

使用柴:

  

assert.isNull(FOO);

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

答案 2 :(得分:3)

免责声明:我是assertthat模块的作者,我将在本回答中提及。

基本上,您可以使用Node自己的assert模块来完成所有其他事情,例如Should.jsexpect.js或{{3 }}。他们的主要区别在于你如何表达自己的意图。

从语义上讲,以下几行代码都是相同的:

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

从语法上讲,有两个主要区别:

首先,should语法仅在foo不等于nullundefined时才有效,因此它不如其他语法。其次,可读性存在差异:虽然assert.that(...)读取的内容与自然语言类似,但其他所有内容都没有。

毕竟,Chai只是几个断言模块的包装器,可以让你更轻松。

所以,长话短说:不,没有技术上的理由为什么要优先选择其中一个,但可读性和null兼容性可能是原因。

我希望这会有所帮助: - )

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

答案 3 :(得分:1)

由于没有人提到它,我想我会提到rockstar程序员Guillermo Rauch's article(链接到Web存档备份),说明为什么你应该避免使用期望式框架来支持更简洁的assert样式测试。 / p>

请注意,他是expect.js的作者,所以他曾经不这么认为。我也是。

他做了一个详尽的论证,但基本上是关于减少API重载的精神负担。我永远不会记住哪种方言应该和我期待写作。它是.includes(foo).to.be.true()还是.includes(foo).to.be.true还是它......

TJ Holowaychuck写了一个名为better-assert的好的断言库,以获得更好的输出which you might check out

相关问题