[译]从新思考单元测试断言

原文地址：https://medium.com/javascript-scene/rethinking-unit-test-assertions-55f59358253f

做者：Eric Elliott

「断言」是编程术语，表示为一些布尔表达式，程序员相信在程序中的某个特定点该表达式值为真，能够在任什么时候候启用和禁用断言验证，所以能够在测试时启用断言而在部署时禁用断言。一样，程序投入运行后，最终用户在遇到问题时能够从新启用断言。

每当测试失败的时候，靠谱的自动化测试总能生成一份优秀的错误报告（bug report），可是不多有开发者花时间去思考一个好的错误报告须要哪些信息。

在此以前，我已经详细地叙述过 每一个单元测试必须回答的 5 个问题 ，因此此次咱们将它们一笔带过。

1. 被测单元是什么（模块，函数，类，等等）？
2. 它将作什么？
3. 实际输出是什么？
4. 指望的输出是什么？
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 个问题：

1. 被测单元是什么？ addEntity()
2. 它将作什么？ should add the new entity
3. 实际输出是什么？ 哎呀，咱们不知道。咱们没有将这些数据提供给测试框架。
4. 指望的输出是什么？ 咱们再一次的不知道。咱们这里没有测试返回值。相反，咱们假设它不抛出，一切都按照预期运行——可是若是没有呢？若是函数返回一个值或者是 promise ，咱们应该测试结果值。
5. 如何将失败重现？ 咱们能够在测试设置中看到这一点，但咱们能够更明确地说明这一点。例如，对你输入的东西进行简单的描述以便让咱们更好地理解测试用例的意图。

满分为 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() 块中，它的第一个参数将做为单元测试的一个标签。完整的测试以下：

describe('sum()', async assert => {
  assert({
    given: 'no arguments',
    should: 'return 0',
    actual: sum(),
    expected: 0
  });
});

它的运行结果以下所示：

TAP version 13
# sum()
ok 1 Given no arguments: should return 0

让咱们再看看上面的 2.5 分的测试，看看咱们可否提升咱们的分数：

describe('addEntity()', async assert => {
  const myEntity  = { id: 'baz', foo: 'bar' };
  const given =  'an entity';
  const should = 'read the same entity from the api';
  try {
    const response = await addEntity(myEntity);
    const storedEntity = await getEntity(response.id);
    assert({
      given,
      should,
      actual: storedEntity,
      expected: myEntity
    });
  } catch(error) {
    assert({
      given,
      should,
      actual: error,
      expected: myEntity
    });
  }
});

1. 被测单元是什么？ addEntity()
2. 它将作什么？ given an entity: should read the same entity from the api
3. 实际输出是什么？ { id: 'baz', foo: 'bar' }
4. 指望的输出是什么？ { id: 'baz', foo: 'bar' }
5. 如何将失败重现？ 如今，消息中更明确地说明了如何重现测试：提供 given 以及描述。

很好！如今咱们经过了测试的测试。

一个深度相等断言已经足够了吗？

在过去的一年半中的几个大型项目中，我几乎天天都使用 RITEway。经过界面的简单化，咱们将其提高了一些，可是我历来没有想过另外的断言，咱们的测试套件是我在整个职业生涯中见过的最简单，最易读的测试套件。

我认为是时候与世界其余地方分享这项创新了。若是你想开始使用 RITEway ：

npm install --save-dev riteway

它会改变你对测试软件的见解。

简而言之：

测试越简单越好（Simple tests are better tests）

附：我在本文中一直使用 “单元测试” 这个术语，这仅仅是由于它比 “自动化软件测试” 或 “单元测试、功能测试以及集成测试” 更容易写，可是我在本文中所说的关于单元测试的全部内容都适用于我能想到的每一个自动化软件测试。我也喜欢这些比 Cucumber/Gherkin 更好的测试。

下一步

EricElliottJS.com 的会员能够得到有关测试驱动开发的视频课程，若是你还不是会员，请当即前往 注册 。

Eric Elliott 是 “Programming JavaScript Applications” （O’Reilly）的做者，也是软件导师平台 DevAnywhere.io 的创始人。 他为 Adobe Systems，Zumba Fitness，华尔街日报，ESPN，BBC 以及包括 Usher，Frank Ocean，Metallica 等在内的顶级录音软件的用户体验作出了杰出贡献。