浅谈软件单元测试中的“断言” (assert) -- 从石器时代进步到黄金时代

Posted 2023-05-15

参考技术A 大家都知道，在软件测试特别是在单元测试时,必用的一个功能就是“断言”（Assert)，可能有些人觉得不就一个Assert语句，没啥花头，也有很多人用起来也是懵懵懂懂，认为只要是Assert开头的方法，拿过来就用。一个偶然的机会跟人聊到此功能，觉得还是有必要在此整理一下如何使用以及对“断言”的理解。希望可以帮助大家对此有一个系统的理解，也趁机聊聊“断言”发展一路过来的心路历程。

首先稍微介绍一下断言相关知识，对于有经验的程序员请移步到下面的“断言”进化史部分。

在单元测试时，程序员预计在程序运行到某个节点位置，需要判断某些逻辑条件必须满足，这样下面的一些业务逻辑才可以进行下去，如果不满足，程序就会"报错"甚至是"崩溃"。比如说，一段程序是负责“转账”，在真正开始转账操作前首先需要“断言”这个账户是一个“合法”的账户，比如账户不是 null 。当出现些状况时，程序开发人员就可以在第一时间知道这个问题，可以去 debug 除错，而非等到交付给用户后才发现问题。其实这个功能是TDD (Test Driven Develop)的基石之一。

一开始的一些单元测试框架（比如JUnit）提供的断言语句，这样在程序某个地方确保某个逻辑关系肯定返回是true,如果不是true,这个单元测试就是没有测试通过。如下就是一个例子,如果程序运行到此行时返回false程序就会抛出一个错误（如下图一）并停止运行，开发人员可以去检查下为什么出现此问题。非常的简单粗爆。

上面这种断言除了简单之外，是有一个问题，就是当断言被触发时显示出来的错误消息不是很友好。如上图一，只是知道出错了，但是并没有太多有用的信息，比如最好是能显示出x与y的值来，这样好更快的理解为啥出错。后来，支持断言的单元测试框架升级版本出现了，它们提供了一系列的高级”断言“语句，添加了一些更加友好的程序接口，同时还提供比较亲民的错误消息，比如下面的例子使用了两个单独的断言语句。

执行的结果如下图二，你可以看到这个错误结果相对于上面“石器时代”已经包括了不少有用的信息，比如除了知道断言失败外还显示了 期望的值 以及 实际值 。

但是上面这种方式有一个弊端，就是需要大量的预置断言方法（比如判断相等一个方法，判断不相等一个方法等），去支持各种场景。接下来又出现了新的解决方案，其中的明星就是 Hamcrest (其实这个词是使用一种叫做 angram 的文字游戏，即把一个原来单词中的字母顺序改变，这个Hamcrest就是从Matchers的变形)框架。是使用一种 assertThat 组合上 Matcher 来使用。

这个有多个好处，

上面说了这么多，是不是感觉平时经常使用的一个看似简简单单的Assert还有不少的东西可以深挖一下滴。这个只是抛砖引玉，如果大家还有什么点子或建议请使用下面的方式。

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

原文地址：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 等在内的顶级录音软件的用户体验做出了杰出贡献。