Node.js断言库与其他断言库的比较

Node.js assert library vs. other assert libraries

本文关键字：断言 比较 其他 Node js      更新时间：2024-01-20

根据node.js断言库文档：

该模块旨在供Node.js内部使用，但可以在应用程序代码通过require（"assert"）。但是，assert不是测试框架，不打算用作一般用途断言库。

我将Chai视为一个替代的断言库（没有BDD API，只有assert API），最后我发现assert功能非常相似。

为什么柴的断言库是一个更好的断言库？它比node.js做任何事情（除了在可用断言方面更丰富之外，但这只是语法上的糖衣）。即使是像执行断言的总计数这样简单的事情，在这两种情况下也不可用。

我是不是错过了什么？

UPDATE（2017年4月）：Node.js不再警告人们不要使用assert，因此下面的答案已经过时。不过，为了历史利益而离开它。

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

https://github.com/nodejs/node/issues/4532以及其他问题暗示了文档建议不要使用assert进行单元测试的原因：存在边缘情况错误（或者至少肯定是意外的）和功能缺失。

更多的上下文：知道我们现在所知道的，如果我们重新设计/构建Node.js核心，assert模块要么不存在于Node.js中，要么由更少的函数组成——很可能只有assert()（目前是assert.ok()的别名）。

至少从我的角度来看，这样做的原因是：

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

其他人可能会选择在这里添加或不添加其他上下文（例如，为什么在所有条件相同的情况下，我们倾向于保持核心较小，并在用户区内做事）。但这就是所谓的30000英尺的视野。

由于assert在Node.js中已经存在很长时间了，而且很多生态系统都依赖于它，所以我们不太可能（至少据我目前所知）删除assert.throws()和朋友。它会打碎太多东西。但是，我们可以阻止人们使用assert，并鼓励他们使用由那些非常关心他们的人维护的用户土地模块，他们积极修复边缘案例错误，并在有意义的时候添加很酷的新功能。这就是一切。

的确，如果您使用简单的案例进行直接断言，assert可能会满足您的需求。但是，如果你的年龄超过了assert，那么使用chai或其他什么会更好。因此，我们鼓励人们从那里开始。这对他们（通常）更好，对我们（通常）也更好。

我希望这是有帮助的，并回答你的问题。

我想，由于没有人给我任何好的反馈，在使用node.js的assert和chai的assert一段时间后，我会尝试对我最初的问题提供一些线索。

最终的答案是，在功能方面，它们是相同的。chai断言存在的唯一原因是，如果你阅读代码，你可以更好地理解测试，但仅此而已

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

assert（foo===null）；

使用chai:

assert.isNull（foo）；

它们是完全等效的，并且坚持使用node.js断言会限制依赖列表。

免责声明：我是这个答案中提到的模块的作者

基本上，您可以使用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不等于null或undefined时才有效，因此它不如其他语法。其次，可读性存在差异：虽然assert.that(...)读起来像自然语言，但其他所有语言都不一样。

毕竟，Chai只是一些断言模块的包装器，让事情对您来说更容易。

所以，长话短说：不，没有技术上的理由喜欢一个而不是另一个，但可读性和null兼容性可能是原因。

我希望这有帮助：-）

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

既然没有人提到它，我想我会提到摇滚明星程序员Guillermo Rauch的文章（链接到Web档案备份），说明为什么应该避免期望的风格框架，而选择更简单的assert风格测试。

请注意，他是expect.js的作者，所以他曾经有过不同的想法。我也是。

他提出了一个详尽的论点，但基本上是为了减轻API过载的精神负担。我永远都记不起我应该写哪种方言了。是.includes(foo).to.be.true()还是.includes(foo).to.be.true还是。。。

TJ Holowaychuck编写了一个名为better-assert的断言库，以获得更好的输出，您可以查看。

相关文章：