Testing library 101 (一)

概述

Testing-library 是 React 官方推荐的单元测试库,对标的是 Airbnb 的 Enzyme。我试着用现在流行的一套话术体系(发现问题、分析问题、解决问题)来解释一下 Testing-library 的特点:

  1. Testing-library 的设计者发现了一个问题:从前的 unit test 主要着眼于组件内部属性的断言,但是开发者们觉得这种测试方法有点自欺欺人

  2. 为了提升开发者对自己 test case 的信心,他们提出了一个理念:只有更接近于软件使用方式的测试,大家才觉得更可靠

  3. 然后他们设计了一堆 API,来模拟用户找寻或操作 DOM 的方式

OK,一句话解释就是 Testing-library 提供了一系列拟人化的 API 来帮助我们测试 UI 组件。至于如何拟人化,请看下方示例。

安装

本文以 react 为例,如果大家使用的是 create-react-app 新建的应用,可以跳过本章;如果没有,就需要安装如下两个依赖:

yarn add -D @testing-library/react @testing-library/user-event

这里说明一下,testing-library 是 library 不是 framework。Framework 遵守的是好莱坞原则(Don't call me, I'll call you), 而 library 通常需要主动 import 方法。testing-library 实现了所有主流测试框架的集成,本文选用了 React 官推的 Jest+testing-library 组合,所以还需要安装@testing-library/jest-dom

yarn add - D @testing-library/jest-dom

方便起见,通常还会给 jest 添加一个启动文件用于导入@testing-library/jest-dom;当然你也可以省略这一步,只是每个测试文件里都要加下面这一句,有点麻烦罢了。

// setupTests.js
import "@testing-library/jest-dom";
// package.json
{
  "jest": {
    "setupFilesAfterEnv": ["setupTests.js"]
  }
}

Get started

安装完成后,我们就开始第一个 test case。先写一个 Hello World 的组件:

// Title.js
import React from "react";
export const Title = () => <h1>Hello World</h1>;

React Testing Library(以下简称RTL)的测试内容大致如下,通过一个叫 render 的方法来渲染 React 组件(VUE,Angular, Svelte 框架相关的 Testing Library 测试也大体相同):

// Title.test.js
import React from "react";
import { Title } from "./Title";
+ import { render } from "@testing-library/react";

describe("Title", () => {
  test("debug Title", () => {
+    render(<Title />);
  });
});

一般初学者都想看一下 render 的结果,那试试 screen.debug()

// Title.test.js
import { render, screen } from "@testing-library/react";

describe("Title", () => {
  test("debug Title", () => {
    render(<Title />);

    screen.debug();
  });
});

运行jest,控制台输出如下:是一块 html document。React 组件的 DOM 被包裹在<body>——render 函数默认的 container——里面。

<body>
  <div>
    <h1>Hello World</h1>
  </div>
</body>

通常来说,我们写 test case 不会直接打印出这个渲染的 DOM,但是大家心里得明白,所有的测试方法都是基于这个 render 方法的渲染结果。

选择元素

当然,仅仅利用库方法渲染出 Document 并不能称为一个测试用例;我们至少需要一个断言:比如,断定某个元素会出现在渲染后的 Document 中。我们在 render 后加上如下两行代码:

// Title.test.js
test("getByText of Title", () => {
  render(<Title />);
+  const $e = screen.getByText("Hello World");
+  expect($e).toBeInTheDocument();
});

解释一下:

  1. 利用 getByText 找到一个包含文本 Hello World 的一个元素
  2. 断言这个元素在 Document 中

再次运行jest,测试通过;一个最最基础的 test case 就完工了。

Title
    √ getByText of Title (29 ms)

Test Suites: 1 passed, 1 total
Tests:       1 skipped, 1 passed, 1 total

上面这个 case 中,我们用到了 getByText——利用文本查看目标元素,大家有没有觉得很像某个场景:在浏览器里对着某段文本 inspect,然后找到目标元素呢?这就是 RTL API 的独特之处:模拟开发者的用例操作。

此外,还有如下几个 API 也能帮我们查看元素。但是大家有没有注意到,这里竟然没有选择器(selector)?!这就是上文提到的拟人化特色:你不用去深入了解组件内部具体用到了什么 ID,或是什么类;你只需模糊地意识到有这么一个 html tag 就可以开始测试了。

  • getByRole('button'): <button>click me</button>
  • getByLabelText('search'): <label for="search" />
  • getByPlaceholderText('Search'): <input placeholder="Search" />
  • getByAltText('profile): <img alt="profile" />
  • getByDisplayValue('Javascript): <input value="JavaScript" />

搜索变量

getByText

我们接着说getByText。上文用到 getByText('Hello World'),用的是全文本匹配搜索,事实上该方法还支持正则表达式。下面这个 case 也能过;只要知道某个文本的变量,getByText 就可以帮忙搜索到目标元素了。

test("getByText by regular expression", () => {
  render(<Title />);
  const $e = screen.getByText(/Hello/);
  expect($e).toBeInTheDocument();
});

queryByText

getByText 之外,RTL 还提供了个一个类似的方法,叫 queryByText。它俩的区别是:getByText 找不到元素时,会直接抛异常,test case 会随之中断报错;而 queryByText 在这种情况下是返回 null,所以 queryBy 常用于断言某个元素不存在于 Document 中。这种测试挺常见的,比如传个参数到组件里让它隐藏掉某个元素什么的。

test("search queryByText of Title", () => {
  render(<Title />);
  const $e = screen.queryByText(/Onion/);
  expect($e).toBeNull();
});

findByText

第三个类似的方法叫 findByText,它是一个异步函数;用在一些需要异步渲染的组件测试上:

// AsyncTitle.js
import React, { useState, useEffect } from "react";

export const AsyncTitle = () => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    const loadUser = async () => {
      await "simulate a promise";
      setUser("Onion");
    };
    loadUser();
  });

  return user && <h1>Hello {user}</h1>;
};
// AsyncTitle.test.js
test("findByText of AsyncTitle", async () => {
  render(<AsyncTitle />);
  const $e = await screen.findByText(/Hello/);
  expect($e).toBeInTheDocument();
});

多元素选择

上面提到的都是选择第一个出现的元素。自然有全选的情况,API 也是类似上述的三套——getAllByqueryAllByfindAllBy。每套 API 又包含TextRolePlaceholderText等等。全选搜索返回的就是一个数组,测试方法类似,就是多了个循环罢了,这里就不展开了。

事件

接着我们再谈谈怎么测试 UI 的事件。我们不看源码,只看组件 UI 效果。

input

该组件的功能简单来说就是:在输入框内输入文字,它上头就会显示相应的文本。如果你是 tester,你会怎么测试?我想具体来说就三步:

  1. 选中输入框
  2. 输入文字
  3. 确认输入的文本已显示

看看我们的 unit test 怎么写:

// InputTitle.test.js
import userEvent from "@testing-library/user-event";

test("type InputTitle", () => {
  render(<InputTitle />);
  // Step 1
  const $input = screen.getByRole("textbox");

  // Step 2
  const val = "Hello World";
  userEvent.type($input, val);

  // Step 3
  const $text = screen.getByText(val);
  expect($text).toBeInTheDocument();
});

是不是挺直观的?

  1. 找到输入框 $input;这里 <input> 标签的 role 是 textbox(不知道 role 是啥?没关系,getByRole(瞎写一个),控制台会告诉你的)

  2. userEvent.type 来模拟用户输入文字

  3. 再断言相应的输入文本已经显示在 Document 里了

回过头来看一眼这个组件的源码;大家有没有感受到,即便不知道具体实现,也是可以写 UI 测试的?

// InputTitle.js
import React, { useState } from "react";

export const InputTitle = () => {
  const [head, setHead] = useState("");

  return (
    <div>
      <h1>{head}</h1>
      <input
        type="text"
        value={head}
        onChange={(e) => setHead(e.target.value)}
      />
    </div>
  );
};

最后,再说一下上面用到的 @testing-library/user-event 库, 它为 RTL 提供了一整套用户操作集: 除了type,还包括如下几种,大家有空可以试一下,都非常直观。

  • click(element, eventInit, options)
  • dblClick(element, eventInit, options)
  • type(element, text, [options])
  • upload(element, file, [{ clickInit, changeInit }])
  • clear(element)
  • selectOptions(element, values)
  • deselectOptions(element, values)
  • tab({shift, focusTrap})
  • hover(element)
  • unhover(element)
  • paste(element, text, eventInit, options)
  • specialChars

小结

好多老前端都不写 unit test,一说原因就是 UI 测试太难写了。这期看了 RTL 的入门案例,大家有没有动摇呢;其实前端测试也没那么难写,是吧?

这期是 Testing-library 101 的上篇,下篇将包括一些进阶版的测试案例,如回调、异步更新、错误捕获等等,有兴趣的小伙伴可以点击下文连接。

推荐阅读更多精彩内容