原文地址：https://medium.com/javascript-scene/rethinking-unit-test-assertions-55f59358253f
作者：Eric Elliott
「断言」是编程术语，表示为一些布尔表达式，程序员相信在程序中的某个特定点该表达式值为真，可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新启用断言。
每当测试失败的时候，靠谱的自动化测试总能生成一份优秀的错误报告（bug report），但是很少有开发者花时间去思考一个好的错误报告需要哪些信息。
在此之前，我已经详细地叙述过 每个单元测试必须回答的 5 个问题 ，所以这次我们将它们一笔带过。
- 被测单元是什么（模块，函数，类，等等）？
- 它将做什么？
- 实际输出是什么？
- 期望的输出是什么？
- 如何将失败重现？
许多测试框架允许你忽略这些问题中的一个或者多个，这会导致错误报告并不实用。
让我们看一下使用一个虚拟测试框架的示例，该框架提供常用的 pass() 以及 fail() 断言。
describe('addEntity()', async ({ pass, fail }) => { const myEntity = { id: 'baz', foo: 'bar' }; try { const response = await addEntity(myEntity); const storedEntity = await getEntity(response.id); pass('should add the new entity'); } catch(err) { fail('failed to add and read entity', { myEntity, error }); } });我们走在正确的轨道上，但是我们遗漏了一些信息。让我们尝试使用此测试中提供的数据回答 5 个问题：
- 被测单元是什么？
addEntity() - 它将做什么？
should add the new entity - 实际输出是什么？ 哎呀，我们不知道。我们没有将这些数据提供给测试框架。
- 期望的输出是什么？ 我们再一次的不知道。我们这里没有测试返回值。相反，我们假设它不抛出，一切都按照预期运行——但是如果没有呢？如果函数返回一个值或者是
promise，我们应该测试结果值。 - 如何将失败重现？ 我们可以在测试设置中看到这一点，但我们可以更明确地说明这一点。例如，对你输入的东西进行简单的描述以便让我们更好地理解测试用例的意图。
满分为 5 分的情况下，我的得分为 2.5 分。这项测试没有完成它应尽的职责。显然没有回答每个单元测试必须回答的 5 个问题。
大多数测试框架的问题在于它们的功能太过强大，你可以轻松地使用它们提供的各种 “方便（convenient）” 断言，以至于忘记了在测试失败时实现测试的最大价值。
在失败阶段，编写测试问题让我们更加容易弄清楚出了什么问题。
在 每个单元测试必须回答的 5 个问题 ，我这样写道：
equal() 是我最喜欢的断言。如果每个测试套件中唯一可用的断言是 equal()，那么世界上几乎所有的测试套件都会更好。
自从我写这篇文章以来的几年里，我一直坚持着我的这一信念。虽然测试框架忙于添加更多 “方便” 断言，但我却在 Tape（译者注：一个开源测试框架） 上进行了一层简单的封装，使它只暴露了一个深度的相等断言。换句话说，我最低程度地使用了 Tape 库，并删除了一些功能，以提高测试体验。
在 RITE Way 测试原则的影响下，我将封装库称为 RITEway。RITE Way 测试应该是这样的：
- 可读（ Readable ）
- 隔离（ Isolated ）（用于单元测试）或集成（ Integrated ）（用于功能或集成测试，测试应该隔离并且集成组件 / 模块）
- 彻底（ Thorough ）
- 明确（ Explicit ）
RITEway 强制你编写可读，隔离以及彻底的测试，因为这是你使用 API 唯一的方法。由于编写测试断言是如此简单，以至于你将沉迷于编写测试，这使得你更容易进行彻底的测试。
这是 RITEway 中 assert() 的 函数签名：
assert({ given: Any, should: String, actual: Any, expected: Any }) => Void断言必须位于一个 describe() 块中，它的第一个参数将作为单元测试的一个标签。完整的测试如下：
