Node.js断言库与其他断言库
根据node.js声明库文件 ：
该模块旨在供Node.js内部使用，但可以通过require（'assert'）在应用程序代码中使用。 但是，assert不是一个testing框架，不能用作通用的断言库。
我将Chai视为另一个断言库（没有BDD API，只有assert API），最后我发现断言function非常相似。
为什么柴的断言库是一个更好的断言库？ 它比node.js所做的一切都做得更好（除了在断言方面更丰富之外，这只是语法上的糖衣）。 即使简单的事情，如执行断言的总数不是两个都可用。
我错过了什么吗？
更新（2017年4月）：Node.js不再警告人们使用assert所以下面的答案现在已经过时。 但是，为了历史的利益而离开它。
这是我在Node.js问题跟踪器上发布的一个非常类似的问题的答案 。
https://github.com/nodejs/node/issues/4532和其他问题暗示了文档build议不要使用assert进行unit testing的原因：存在边界错误（至less肯定是意外）和缺less的特性。
更多的上下文：知道我们现在知道的，如果我们重新devise/构buildNode.js核心， assert模块将不会存在于Node.js中，或者包含更less的函数 – 很可能只是assert() （这是当前assert.ok()的别名）。
至less从我的angular度来看，原因是：
- 所有在
assert中完成的东西可以很容易地在userland中完成 - 核心的努力最好在别处完成，而不是完善在用户级可以完成的unit testing模块
还有一些其他的内容可能会被其他人select添加或者不添加（比如为什么，所有的东西都是平等的，我们会倾向于保持核心的小，并在用户空间中做事）。 但那就是所谓的三万英尺的观点。
由于assert已经在Node.js中使用了很长时间，并且很多生态系统都依赖于它，所以我们不可能（至less现在可以告诉我的）最好删除assert.throws()和朋友。 这会打破太多的东西。 但是，我们可以阻止人们使用assert并鼓励他们使用用户级模块，这些用户级模块由深入关注它们的人维护，并且积极修复边界错误，并且在有意义时添加很酷的新特性。 所以就是这样。
诚然，如果你用简单的情况做直截了当的断言， assert可能会满足你的需求。 但是，如果你长大了，你会更好的chai或什么。 所以我们鼓励人们从那里开始。 对他们（通常）更好，对我们更好（通常）。
我希望这是有帮助的，并回答你的问题。
我想因为没有人给我任何好的反馈，所以我会试着在我的原始问题上提供一些关于node.js assert和chai的assert的工作。
最后的答案是function方面，它们是相同的。 柴的断言存在的唯一原因是如果你阅读代码，你可以更好地理解testing，但是这是关于它的。
例如，使用Node.jstestingnull值：
assert（foo === null）;
并用chai：
assert.isNull（FOO）;
他们是完全等价的，并坚持node.js断言限制你的依赖列表。
免责声明：我是该模块的作者，我将在这个答案中提到。
基本上，你可以用Node自己的assert模块来实现所有的function，你可以使用其他所有模块，比如Should.js ， expect.js或assertthat 。 他们的主要区别是如何expression意图的方式。
从语义上讲，以下几行代码都是相互等价的：
assert.areEqual(foo, bar); foo.should.be.equal(bar); expect(foo).to.be(bar); assert.that(foo).is.EqualTo(bar);
在语法上，有两个主要区别：
首先，如果foo不等于null或undefined ，那么should语法才起作用，因此它不如其他types。 其次，在可读性方面存在差异：虽然assert.that(...)是像自然语言一样读取，但是其他所有的都不是。
毕竟，Chai只是一些断言模块的封装，让你更容易。
因此，简而言之：不，没有技术上的原因，为什么select一个而不是另一个，但可读性和null兼容性可能是原因。
我希望这有帮助 ：-）
PS：当然，在内部，它们可能会以不同的方式实施，所以可能会有微妙的事情发生，例如平等是如何检查的。 正如在免责声明中所说，我是断言我可能有偏见的作者，但在过去的几年中，我不时地断言这比其他的更可靠，但正如我所说的，失之偏颇。