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

每当测试失败的时候，靠谱的自动化测试总能生成一份优秀的错误报告（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 个问题，我这样写道：

自从我写这篇文章以来的几年里，我一直坚持着我的这一信念。虽然测试框架忙于添加更多 “方便” 断言，但我却在 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
    });
  }
});

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

很好！现在我们通过了测试的测试。

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

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

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

npm install --save-dev riteway

它会改变你对测试软件的看法。

简而言之：

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

下一步

EricElliottJS.com 的会员可以获得有关测试驱动开发的视频课程，如果你还不是会员，请立即前往注册。

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

格子熊

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

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

下一步