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

Question

根据node.js断言库文档

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

我把印度茶看作是一个替代的断言库(没有BDD，只有assert )，最后我看到了断言功能非常相似。

为什么柴的断言库是一个更好的断言库？它所做的一切都比node.js所做的(除了在断言方面更丰富，但这只是语法糖衣)。即使是简单的事情，如执行的断言总数，在这两种情况下都不可用。

我漏掉了什么吗？

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中做的所有事情都可以很容易地在userland中完成。
• 与其完善可以在userland中完成的单元测试模块，不如将核心工作花在其他地方。

还有其他人可以选择在这里添加或不添加的上下文(例如，在所有条件相同的情况下，我们都倾向于将核心保持较小，并在用户土地上进行操作)。但这就是所谓的三万英尺观景。

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

的确，如果您使用简单的案例进行简单的断言，assert可能会满足您的需要。但是，如果你的成长超过了assert，你会更好地使用chai或其他任何东西。所以我们鼓励人们从那里开始。这对他们(通常)更好，对我们(通常)更好。

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

Answer 2

我想，由于没有人给我任何好的反馈，经过一段时间的node.js断言和chai断言的工作之后，我将尝试提供一些关于我最初问题的说明。

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

例如，用Node.js测试空值：

断言(foo === null)；

并使用chai：

assert.isNull(foo)；

它们是完全等价的，坚持node.js断言限制了您的依赖列表。

Answer 3

免责声明:我是 断言 模块的作者，我将在这个答案中提到这个模块。

基本上，您可以使用Node非常自己的assert模块来完成所有其他模块，比如Should.js、expect.js或断言。他们的主要区别在于你如何表达你的意图。

从语义上讲，以下代码行都是等价的：

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(...)读起来像自然语言，但其他语言却不一样。

毕竟，柴只是几个断言模块的包装器，可以简化您的工作。

因此，长话短说:不，没有任何技术上的理由为什么选择一个而不是另一个，但可读性和null兼容性可能是原因。

我希望这会有所帮助：)

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