概述
Testing-library 是 React 官方推荐的单元测试库，对标的是 Airbnb 的 Enzyme。我试着用现在流行的一套话术体系（发现问题、分析问题、解决问题）来解释一下 Testing-library 的特点：
-
Testing-library 的设计者发现了一个问题：从前的 unit test 主要着眼于组件内部属性的断言，但是开发者们觉得这种测试方法有点自欺欺人
-
为了提升开发者对自己 test case 的信心，他们提出了一个理念：只有更接近于软件使用方式的测试，大家才觉得更可靠
-
然后他们设计了一堆 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();
});
解释一下：
- 利用
getByText找到一个包含文本Hello World的一个元素 - 断言这个元素在 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 也是类似上述的三套——getAllBy、queryAllBy、findAllBy。每套 API 又包含Text、Role、PlaceholderText等等。全选搜索返回的就是一个数组，测试方法类似，就是多了个循环罢了，这里就不展开了。
事件
接着我们再谈谈怎么测试 UI 的事件。我们不看源码，只看组件 UI 效果。
input
该组件的功能简单来说就是：在输入框内输入文字，它上头就会显示相应的文本。如果你是 tester，你会怎么测试？我想具体来说就三步：
- 选中输入框
- 输入文字
- 确认输入的文本已显示
看看我们的 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();
});
是不是挺直观的？
-
找到输入框
$input；这里<input>标签的 role 是textbox（不知道 role 是啥？没关系，getByRole(瞎写一个)，控制台会告诉你的） -
用
userEvent.type来模拟用户输入文字 -
再断言相应的输入文本已经显示在 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 的上篇，下篇将包括一些进阶版的测试案例，如回调、异步更新、错误捕获等等，有兴趣的小伙伴可以点击下文连接。
网友评论