w3ctech

[Jest]单元测试初学者指南 - Part1 - 函数测试

原文: Unit Testing Beginner's Guide - Part 1 - Testing Functions

作者：jstweetster

示例代码

你已经决定开始对代码进行单元测试，但是不知道从哪里开始或者围绕该代码的最佳实践是什么。

在这个系列中，我计划在从基本原理开始，并使用您可能直到现在才知道的高级技术，在单元测试的领域中引导你。

开始之前，你需要安装如下依赖：

  • NodeJS - 你也许已经安装啦
  • Jest - 这是我们将会使用的单元测试库

请注意下面事项：

  1. 确保你已经安装了NodeJS：node -v。确保版本号 >= 6.x，如果不是请安装
  2. 创建名为unit-testing-functions目录
  3. 切换到该目录cd unit-testing-functions并且初始化该JavaScript项目：npm init--yes
  4. 现在在该目录你应该有一个package.json文件
  5. 安装Jest：nom i jest --save-dev
  6. 你现在可以验证Jest是否安装成功通过运行：./node_modules/.bin/jest -v

一切准备就绪，我们开始进入单元测试啦。

我们将从简单的函数开始，并且，随着我们进行一系列的单元测试，我们将会继续探索更复杂的数据结构和设置。

我们将会测试的代码

让我们开始定义一个简单的函数：

在unit-testing-functions项目中创建一个sum.js文件。定义如下函数：

module.export = function sum (a, b) {
    return a + b;
}

这个函数我们将会进行测试。单元测试背后的想法是提供尽可能多的输入类型，以涵盖所有条件分支。

现在，没有任何条件分支，但我们应该改变我们对函数的输入，以确保它继续正确运行，即使代码在将来被更改。

理解测试文件

每一个你写的代码文件都应该有一个对应的Spec文件，它通常在代码文件旁边。例如：touch sum.spec.js或者手动创建。

在spec文件中，我们将会写测试方法

Jest和其他测试框架将测试组织到测试用例中，为了简单管理和记录，每个测试用例包含多个单独的测试。

让我们添加我们的第一个测试（在sum.spec.js中）：

const sum = require('./sum.js');
describe('sum suite', function () {
  test('should add 2 positive numbers together and return the result', function () {
    expect(sum(1, 2)).toBe(3);
  });
});

如果这看起来令人生畏或不清楚，请不要担心，它会在少数情况下有意义。

那么，这里发生了什么？

const sum = require('./sum.js');

我们引入要测试的函数。我们使用 module.exports 从模块中暴露函数，并且使用 require 引入到要测试的文件中。这是因为Jest在能识别这些结构的NodeJS上运行我们的测试。

此代码不是在浏览器中运行，不使用像Webpack这样的模块打包器，但另一篇文章将会介绍。

接下来，我们定义了测试单元，它将包含所有有关 sum 函数的测试方法。

describe('sum suite', function () {
    // define here the individual tests
})

最后我们添加我们第一个测试（我们将会在上面的测试单元中添加更多的测试）：

test('should add 2 positive numbers together and return the result', function () {
  expect(sum(1, 2)).toBe(3);
});

下面的代码可能也不是很清楚

expect(sum(1, 2)).toBe(3)

这是任何单元测试的构建块，被称作为“断言(assertion)”。断言基本上是一种表达对事物应该如何表现的期望的方式。在我们的示例中，我们期望调用 sum(1, 2) 应该返回的结果是 3 。

toBe 被称作为“匹配器（matcher）”。在 Jest 里有很多的匹配器，每一个匹配器都有助于验证一个特定的方面：比如测试对象是否相等等。

那么，expect 从哪里来的呢？我们也没有从任何地方导入进来。

事实证明，Jest作为全局变量，提供了 describe 、test 、 expect 和一些其他函数，因此你无需导入他们。你可以到 官方文档 查看完整列表

该到我们运行我们的第一个单元测试啦

你可以在我们的项目根目录中直接调用Jest来运行单元测试 ./node_modules/.bin/jest

更好，更跨平台的方式是定义一个NPM脚本来运行这些测试。例如，打开 package.json 文件并且编辑下面的部分：

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
 }

改为：

"scripts": {
    "test": "jest"
 }

运行 npm run test，你将会看到成功的输出：

➜  unit-testing-functions npm run test

> unit-testing-functions@1.0.0 test /Users/zouyuwei/code/web/_SELF/unit-testing-functions
> jest

 PASS  __tests__/sum.spec.js
  sum suite
    ✓ should add 2 positive numbers together and return the result (8ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.74s
Ran all test suites.

很好，你的第一个测试通过了！

现在，快进几周或者几个月，假设你的同事正在研究 sum 函数并且决定更改它的实现方法如下所示：

module.exports = function sum(a, b) {
    return a - b;
}

请更改它（这仅仅只是为了演示）。现在你的同事在提交这些改变之前运行单元测试。输出将会如下所示：

➜  unit-testing-functions npm run test

> unit-testing-functions@1.0.0 test /Users/zouyuwei/code/web/_SELF/unit-testing-functions
> jest

 FAIL  __tests__/sum.spec.js
  sum suite
    ✕ should add 2 positive numbers together and return the result (30ms)

  ● sum suite › should add 2 positive numbers together and return the result

    expect(received).toBe(expected) // Object.is equality

    Expected: 3
    Received: -1

      2 | describe('sum suite', function () {
      3 |   test('should add 2 positive numbers together and return the result', function () {
    > 4 |     expect(sum(1, 2)).toBe(3);
        |                       ^
      5 |   });
      6 | });

      at Object.toBe (__tests__/sum.spec.js:4:23)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        3.303s
Ran all test suites.

通过查看上面的输出信息，能够很容易的得出结论：在 __tests__/sum.spec.js 文件的第四行出错了，如跟踪堆栈所示 at Object.toBe (__tests__/sum.spec.js:4:23) 。因此可以得出结论 expect(sum(1,2)).toBe(3); 这一行出错了。通过检查控制台的输出，我们能够看到，期望的值是 ‘3’，而接收的值是 ‘-1’。

因此，单元测试既是防止回归的一种方式，也是一种活文档。

最后，请更改 a - b 为 a + b 。

扩大单元测试覆盖率

我们进行了第一次测试，并且它涵盖了sum函数中的所有分支，有许多场景我们还没有测试过。

考虑一下测试中的功能，不仅要考虑今天的实现，还要考虑它如何随着时间的推移而发展。我们希望捕获函数停止工作的情况，即使有人修改了它的实现，并添加了额外的检查和分支。

因此，让我们通过创建额外的单元测试来扩展测试范围。在 sum.spec.js 文件中添加如下代码：

const sum = require('../sum.js');
describe('sum suite', function () {
  test('should add 2 positive numbers together and return the result', function () {
    expect(sum(1, 2)).toBe(3);
  });

  test('Should add 2 negative numbers together and return the result', function() {
    expect(sum(-1, -2)).toBe(-3);
  });

  test('Should add 1 positive and 1 negative numbers together and return the result', function() {
    expect(sum(-1, 2)).toBe(1);
  });

  test('Should add 1 positive and 0 together and return the result', function() {
    expect(sum(0, 2)).toBe(2);
  });

  test('Should add 1 negative and 0 together and return the result', function() {
    expect(sum(0, -2)).toBe(-2);
  });
});

除了最初的测试用例之外，我们刚添加了4个测试用例。注意我们如何改变函数的输入以及我们如何尝试击中边缘情况（例如，通过添加0）。

运行单元测试，你将会看到：

➜  unit-testing-functions npm run test

> unit-testing-functions@1.0.0 test /Users/zouyuwei/code/web/_SELF/unit-testing-functions
> jest

 PASS  __tests__/sum.spec.js
  sum suite
    ✓ should add 2 positive numbers together and return the result (7ms)
    ✓ Should add 2 negative numbers together and return the result (1ms)
    ✓ Should add 1 positive and 1 negative numbers together and return the result (1ms)
    ✓ Should add 1 positive and 0 together and return the result (1ms)
    ✓ Should add 1 negative and 0 together and return the result

Test Suites: 1 passed, 1 total
Tests:       5 passed, 5 total
Snapshots:   0 total
Time:        2.575s
Ran all test suites.

处理单元测试功能中的异常

虽然我们在扩展单元测试覆盖率方面做得很好，但测试可以为我们做更多的事情。

如果我们认为我们还没有涉及的其他方案真的很好，你能想出一些目前代码处理不当的方法吗？

如何传递除数字以外的输入？

填写如下测试用例：

test('Should raise an error if one of the inputs is not a number', function() {
        expect(() => sum('0', -2)).toThrowError('Both arguments must be numbers');
 });

首先，我们用一个匿名函数包装我们要测试的代码：() => sum('0', -2)。

这是必需的，因为在测试一段代码时抛出的任何未捕获的异常都会触发测试失败。

在这个例子当中，当参数不是数据的时候，我们期望 sum 函数抛出异常，但是我们不希望这是被认为是测试失败的： 相反的，这是预期的行为，应该被认为是通过的测试用例。

因此，我们将其包装在一个匿名函数中，并引入一个新的匹配器：toThrowError 。

运行测试，观察如下：

 FAIL  __tests__/sum.spec.js
  sum suite
    ✕ Should raise an error if one of the inputs is not a number (18ms)

  ● sum suite › Should raise an error if one of the inputs is not a number

    expect(function).toThrowError(string)

    Expected the function to throw an error matching:
      "Both arguments must be numbers"
    But it didn't throw anything.

      22 |
      23 |   test('Should raise an error if one of the inputs is not a number', function() {
    > 24 |     expect(() => sum("0", -2)).toThrowError('Both arguments must be numbers');
         |                                ^
      25 |   });
      26 | });

      at Object.toThrowError (__tests__/sum.spec.js:24:32)

此时要抵制修改测试代码的诱惑。

这个测试很清楚的说明了该函数实现上的问题：

  • 它期望函数返回 to throw an error matching:“Both arguments must be numbers 。实际上它没有抛出任何异常。
  • 要查看它正在讨论的函数以及用于调用它的参数，请遵循堆栈跟踪： at Object.toThrowError (__tests__/sum.spec.js:24:32) 。在指定的行和列上，您可以看到对应的断言： expect(() => sum("0", -2)).toThrowError('Both arguments must be numbers'); 。

所以我们的单元测试刚刚发现了一个bug，该是修复的时候了！

更改 sum.js 的代码，以考虑错误的输入类型，并在这种情况下抛出适当的异常：

module.exports = function sum (a, b) {
  if (typeof a !== 'number' || typeof b !== 'number') {
    throw new Error('Both arguments must be numbers');
  }
  return a + b;
}

再次运行测试脚本，观察所有的测试都通过了。好样的！

请注意：我们首先添加了一个单元测试，然后再进入并添加代码，这表明 sum 函数在某些条件下无法正常运行。

我们看到了测试FAILING，我们添加了修复bug的代码并观看了测试PASSING。

在开发新代码/修复现有代码时，您应始终遵循此过程。

提高生产力

到目前为止，您可能已经注意到，每次添加代码或更新单元测试时，我们都必须不断重新运行单元测试。

这很快就会变得烦人并妨碍实际的开发工作流程。幸运的是，大多数测试运行程序允许设置文件监视模式，当磁盘上的文件发生更改时，它会重新运行单元测试。

修改 package.json 文件，将 “script” 部分改为：

"script": {
    "test": "jest --watch"
}

运行单元测试： npm run test

观察现在测试运行器没有退出而是等待命令。

改变 sum.js 或者 sum.spec.js 文件，会看到测试正在重新运行。

单元测试函数 - 最好实践总结

  • 在项目中本地安装测试依赖项，而不是全局安装（例如我们安装 Jest 到 ./node_modules 而不是全局的）。这允许我们在同时处理多个项目，并为每个项目分别升级。此外，它还可以轻松地与他人共享我们的项目设置。
  • 定义一个用于运行单元测试的NPM脚本，你不必再记住确切的测试命令。它还抽象出用于运行测试的实际单元测试运行器。
  • 每个代码文件应该有一个相应的 .spec 文件，通常位于代码文件的旁边（译者觉得：或者是放到统一的测试文件夹中）。这使得某人能够快速浏览与组件相关的测试并了解其工作原理。
  • test 语句的文本说明非常重要：确保它们非常清晰，可读并且能够确定哪些条件下的预期行为。描述文本通常应该遵循如下模板：“[在什么情况下] 应该 [期望什么] ” (Should [what's to be expected] when [under which circumstances])。
  • 单元测试应该只运行一种行为。同一个单元测试不要涵盖多个场景。而是创建场景自己的 test 单元，并且清晰的命名、描述和运用该场景。
  • 在添加实现/修复某些行为的代码之前，始终先编写一个初始的FAILING测试。

这就是我们对单元测试的介绍。

w3ctech微信

扫码关注w3ctech微信公众号

共收到0条回复