测试代码怎么做抽象才是有意义的？

前言

哈喽&＃xff0c;大家好&＃xff0c;我是海怪。

不知道大家在写前端单测的时候&＃xff0c;是否有出现测试代码和测试数据重复冗余的情况&＃xff1f;然后不得不写一些函数和类来封装他们的。然而&＃xff0c;慢慢地会发现&＃xff1a;过度的封装会致使你的测试用例变得越来越难读。

那到底在写测试代码时&＃xff0c;怎样的封装才是好的封装呢&＃xff1f;今天就把 Kent 的这篇 《AHA Testing》 分享给大家~

正片开始

“AHA 编码原则” 指的是 “避免过度的抽象”&＃xff08;Avoid Hasty Abstraction&＃xff09;。我对这如何适用于编写可维护的测试有不一样的感觉。因为我见过太多人写的测试都是在下面这条轴两个极端&＃xff1a;要么是 ANA (Absolutely No Abstraction) 完全没有任何抽象&＃xff0c;要么是 完全 DRY (Don’t Repeat Yourself) 完全不做任何重复【译注&＃xff1a;我觉得这里可以理解为过度抽象】。&＃xff08;ANA 是我现在起的名&＃xff09;

要写出一份高维护性测试代码的关键就是在上面这条轴上找一个最完美的平衡点。

ANA Testing

一个我见过最好的 “完全不做抽象” 的例子就是给 Express 的 Route Handler 写测试。为了能让你理解我这里说的 “用 ANA 写测试是不好的”&＃xff0c;这里给你一个经典的样例&＃xff0c;你来维护好它的代码库和测试用例。可能你现在会觉得这些测试用例也能保障代码质量&＃xff0c;也还好。不过这样的用例真的没问题么&＃xff1f;先让我们来看看这些测试代码来找出下面 Route Handler 中的不同之处吧。

别花太久的时间哦

import * as blogPostController from &＃39;../blog-post&＃39;// load the application-wide mock for the database.
// I guess that means this is AANA (Almost Absolutely No Abstraction)
// but I didn&＃39;t want to write out a whole db mock for this blog post &＃x1f605;
jest.mock(&＃39;../../lib/db&＃39;)test(&＃39;lists blog posts for the logged in user&＃39;, async () &＃61;> {const req &＃61; {locale: {source: &＃39;default&＃39;,language: &＃39;en&＃39;,region: &＃39;GB&＃39;,},user: {guid: &＃39;0336397b-e29d-4b63-b94d-7e68a6fa3747&＃39;,isActive: false,picture: &＃39;http://placehold.it/32x32&＃39;,age: 30,name: {first: &＃39;Francine&＃39;,last: &＃39;Oconnor&＃39;,},company: &＃39;ACME&＃39;,email: &＃39;francine.oconnor&＃64;ac.me&＃39;,latitude: 51.507351,longitude: -0.127758,favoriteFruit: &＃39;banana&＃39;,},body: {},COOKIEs: {},query: {},params: {bucket: &＃39;photography&＃39;,},header(name) {return {Authorization: &＃39;Bearer TEST_TOKEN&＃39;,}[name]},}const res &＃61; {clearCOOKIE: jest.fn(),COOKIE: jest.fn(),end: jest.fn(),locals: {content: {},},json: jest.fn(),send: jest.fn(),sendStatus: jest.fn(),set: jest.fn(),}const next &＃61; jest.fn()await blogPostController.loadBlogPosts(req, res, next)expect(res.json).toHaveBeenCalledTimes(1)expect(res.json).toHaveBeenCalledWith({posts: expect.arrayContaining([expect.objectContaining({title: &＃39;Test Post 1&＃39;,subtitle: &＃39;This is the subtitle of Test Post 1&＃39;,body: &＃39;The is the body of Test Post 1&＃39;,}),]),})
})test(&＃39;returns an empty list when there are no blog posts&＃39;, async () &＃61;> {const req &＃61; {locale: {source: &＃39;default&＃39;,language: &＃39;en&＃39;,region: &＃39;GB&＃39;,},user: {guid: &＃39;0336397b-e29d-4b63-b94d-7e68a6fa3747&＃39;,isActive: false,picture: &＃39;http://placehold.it/32x32&＃39;,age: 30,name: {first: &＃39;Francine&＃39;,last: &＃39;Oconnor&＃39;,},company: &＃39;ACME&＃39;,email: &＃39;francine.oconnor&＃64;ac.me&＃39;,latitude: 31.230416,longitude: 121.473701,favoriteFruit: &＃39;banana&＃39;,},body: {},COOKIEs: {},query: {},params: {bucket: &＃39;photography&＃39;,},header(name) {return {Authorization: &＃39;Bearer TEST_TOKEN&＃39;,}[name]},}const res &＃61; {clearCOOKIE: jest.fn(),COOKIE: jest.fn(),end: jest.fn(),locals: {content: {},},json: jest.fn(),send: jest.fn(),sendStatus: jest.fn(),set: jest.fn(),}const next &＃61; jest.fn()await blogPostController.loadBlogPosts(req, res, next)expect(res.json).toHaveBeenCalledTimes(1)expect(res.json).toHaveBeenCalledWith({posts: [],})
})


找到其中的差别了么&＃xff1f;这里的差别是&＃xff1a;第一例子能够返回一个 Post&＃xff0c;而在第二个用例中不返回这个 Post&＃xff01;那么到底是什么导致两者的差别呢&＃xff1f;还有&＃xff0c;为什么要在第一个用例里 blogPostController.loadBlogPosts(req, res, next) 调用的 res.json 里要返回 Post&＃xff0c;而第二个用例却没有返回呢&＃xff1f;

如果你想不出这些问题的答案。没关系&＃xff0c;等会再说。如果你搞懂了&＃xff0c;说明你很适合玩《大家一起来找猹》这个流。如果都像上面这样写测试&＃xff0c;那么写出来的用例很难让别人阅读和维护。

假如现在有 20 多个这样的测试用例放在一个文件里&＃xff0c;你是不是看着很难受&＃xff1f;你可能会说&＃xff1a;哪有那么夸张&＃xff1f;别笑&＃xff0c;像这样的我见太多了。我举个例子&＃xff1a;

• 一个新人刚到新团队
• 然后被叫去加个测试用例
• 复制一下以前的测试代码&＃xff0c;在上面改改&＃xff0c;感觉没什么问题就提交了
• Review 的人一看&＃xff1a;测试通过了&＃xff0c;代码应该没问题就 Approve 了
• PR 合并

所以&＃xff0c;为了更好地处理这种情况&＃xff0c;你可以思考以下两个问题&＃xff1a;

你的测试用例是否能够很快让人看懂它们之前的差异以及这些差异的来源。

绝对不要写 “完全没抽象” 的测试代码。

DRY Testing

我现在没法给一个很好的 DRY 测试代码的例子。只需要知道&＃xff1a;当想把所有东西都要弄成 DRY 的时候&＃xff0c;测试就会变得非常难以维护了&＃xff0c;比如&＃xff1a;

• 一个新人刚到新团队
• 他被叫去加个测试用例
• 复制以前的测试代码&＃xff0c;然后在测试工具函数中加了一行 if 语句来通过测试
• Review 的人一看&＃xff1a;测试通过了&＃xff0c;代码应该没问题就 Approve 了
• PR 合并

在 DRY 测试中&＃xff0c;我见的很多的另一种情况就是&＃xff1a;滥用 describe 和 it 的嵌套以及 beforeEach。你越是想用嵌套来做变量的共享&＃xff0c;越是难让人搞懂测试代码的逻辑。关于这个问题&＃xff0c;可以看我的 [《Test Isolation with React》])(https://kentcdodds.com/blog/test-isolation-with-react) 这篇文章。

以下为译注内容。 这里作者没有给一个很好的例子&＃xff0c;我这里稍做补充一下。举下面这个例子&＃xff1a;

import { getUserById } from &＃39;src/db/user&＃39;;
import { mockUser, mockAttributes } from &＃39;tests/utils/constants&＃39;;
import { insertUser } from &＃39;tests/utils/db&＃39;;describe(&＃39;测试 DB&＃39;, () &＃61;> {it(&＃39;测试 getUserById&＃39;, async () &＃61;> {const user &＃61; {id: &＃39;123&＃39;,...mockUser,...mockAttributes,}await insertUser(user);const resultUser &＃61; await getUserById(&＃39;123&＃39;);expect(resultUser).toEqual(user);})
})


我们把 mockUser, mockAttributes 以及 insertUser 都放在 tests/utils 下了&＃xff0c;这样去构造测试用例很容易会出现过度抽象。因为对于第一次看这个用例的人来说&＃xff0c;他得先去找 tests/utils/contants 下的 user 相关的数据&＃xff0c;然后再去 tests/utils/db 下找 insertUser 的具体实现&＃xff0c;再然后才能拼凑出一个完整的 user 输入内容。

在最后的 toEqual 里也要回过头来看 user 的内容是啥&＃xff0c;这就导致阅读用例的人会有比较高的心智负担&＃xff0c;他大脑得有一个内存时刻存放着这个 user 的样子&＃xff0c;这样的用例就变得很难让人跟上了&＃xff0c;特别是在一些用例非常多的测试文件中&＃xff0c;这种心智负担会变得越来越重。

所以&＃xff0c;这里更推荐是可以在前面加一个 setup 函数用于生成对应的 user 内容&＃xff0c;然后再在具体的用例中 用非常明显的方式 去添加这个用例的 “独特之处”&＃xff08;比如名字变了之类的&＃xff09;

import { getUserById } from &＃39;src/db/user&＃39;;
import { getMockUser } from &＃39;tests/utils/user&＃39;;
import { insertUser } from &＃39;tests/utils/db&＃39;;const setup &＃61; () &＃61;> {return getMockUser();
}describe(&＃39;测试 DB&＃39;, () &＃61;> {it(&＃39;测试 getUserById&＃39;, async () &＃61;> {const mockUser &＃61; setup();mockUser.name &＃61; &＃39;Jack&＃39;;await insertUser(mockUser);const resultUser &＃61; await getUserById(&＃39;123&＃39;);expect(resultUser.name).toEqual(&＃39;Jack&＃39;);})
})


这里依然把 getMockUser 和 insertUser 放在 tests/utils 中了&＃xff0c;因为别的地方也有可能会用到&＃xff0c;还是得做适量的抽象。不过&＃xff0c;我们这里把 mockUser.name &＃61; &＃39;Jack&＃39; 放在第二行&＃xff0c;那对于第一次看的人来说就知道&＃xff1a;这个用例的重点要关注 name 这个字段。

而后面的 toEqual(&＃39;Jack&＃39;) 也很清晰地让阅读用例的人知道&＃xff1a;你现在期望的结果就是 &＃39;Jack&＃39;&＃xff0c;而不是 mockUser.name&＃xff0c;因为如果写变量的话&＃xff0c;会很人很不放心&＃xff1a;“万一这个变量被改了呢&＃xff1f;”

总的来说&＃xff0c;我们不要过度代入开发的视角&＃xff0c;而要以 文档阅读者 的角度去编写自己的用例&＃xff0c;用例可读性应该优先于代码可读性。

译注结束。

AHA Testing

上面第一个例子绝对是抽象的灾难&＃xff08;不过这也可以作为 AHA 编程思路的一个参考方向&＃xff09;。现在一起来把上面的测试写得更让人容易理解吧。首先我们来理清楚这两个用例的不同之处。

import * as blogPostController from &＃39;../blog-post&＃39;// load the application-wide mock for the database.
jest.mock(&＃39;../../lib/db&＃39;)function setup(overrides &＃61; {}) {const req &＃61; {locale: {source: &＃39;default&＃39;,language: &＃39;en&＃39;,region: &＃39;GB&＃39;,},user: {guid: &＃39;0336397b-e29d-4b63-b94d-7e68a6fa3747&＃39;,isActive: false,picture: &＃39;http://placehold.it/32x32&＃39;,age: 30,name: {first: &＃39;Francine&＃39;,last: &＃39;Oconnor&＃39;,},company: &＃39;ACME&＃39;,email: &＃39;francine.oconnor&＃64;ac.me&＃39;,latitude: 51.507351,longitude: -0.127758,favoriteFruit: &＃39;banana&＃39;,},body: {},COOKIEs: {},query: {},params: {bucket: &＃39;photography&＃39;,},header(name) {return {Authorization: &＃39;Bearer TEST_TOKEN&＃39;,}[name]},...overrides,}const res &＃61; {clearCOOKIE: jest.fn(),COOKIE: jest.fn(),end: jest.fn(),locals: {content: {},},json: jest.fn(),send: jest.fn(),sendStatus: jest.fn(),set: jest.fn(),}const next &＃61; jest.fn()return {req, res, next}
}test(&＃39;lists blog posts for the logged in user&＃39;, async () &＃61;> {const {req, res, next} &＃61; setup()await blogPostController.loadBlogPosts(req, res, next)expect(res.json).toHaveBeenCalledTimes(1)expect(res.json).toHaveBeenCalledWith({posts: expect.arrayContaining([expect.objectContaining({title: &＃39;Test Post 1&＃39;,subtitle: &＃39;This is the subtitle of Test Post 1&＃39;,body: &＃39;The is the body of Test Post 1&＃39;,}),]),})
})test(&＃39;returns an empty list when there are no blog posts&＃39;, async () &＃61;> {const {req, res, next} &＃61; setup()req.user.latitude &＃61; 31.230416req.user.longitude &＃61; 121.473701await blogPostController.loadBlogPosts(req, res, next)expect(res.json).toHaveBeenCalledTimes(1)expect(res.json).toHaveBeenCalledWith({posts: [],})
})


来说说第一个和第二个用例不同之处在哪&＃xff1f;第一个用例的用户在 London&＃xff0c;第二个则在 Shanghai。

只要稍微添加一点点抽象代码&＃xff0c;我们就可以很清晰地分清用例之前的输入和输出的不同&＃xff0c;这样的测试代码就会更容易让人理解和维护。

用 AHA 思想来测 React

当测 React 组件时&＃xff0c;我一般都会有一个 renderFoo 的函数专门用来充当 setup 的作用。比如&＃xff1a;

import * as React from &＃39;react&＃39;
import {render, screen} from &＃39;&＃64;testing-library/react&＃39;
import userEvent from &＃39;&＃64;testing-library/user-event&＃39;
import LoginForm from &＃39;../login-form&＃39;function renderLoginForm(props) {render(<LoginForm {...props} />)const usernameInput &＃61; screen.getByLabelText(/username/i)const passwordInput &＃61; screen.getByLabelText(/password/i)const submitButton &＃61; screen.getByText(/submit/i)return {usernameInput,passwordInput,submitButton,changeUsername: value &＃61;> userEvent.type(usernameInput, value),changePassword: value &＃61;> userEvent.type(passwordInput, value),submitForm: () &＃61;> userEvent.click(submitButton),}
}test(&＃39;submit calls the submit handler&＃39;, () &＃61;> {const handleSubmit &＃61; jest.fn()const {changeUsername, changePassword, submitForm} &＃61; renderLoginForm({onSubmit: handleSubmit,})const username &＃61; &＃39;chucknorris&＃39;const password &＃61; &＃39;ineednopassword&＃39;changeUsername(username)changePassword(password)submitForm()expect(handleSubmit).toHaveBeenCalledTimes(1)expect(handleSubmit).toHaveBeenCalledWith({username, password})
})


如果像上面只有两、三个测试用例&＃xff0c;或者测试代码很短的话&＃xff0c;我会觉得这有点过早优化了。但如果你的用例都是各自有一些细微区别&＃xff08;比如错误状态等&＃xff09;&＃xff0c;那么像这样去做抽象就是很好的。

Nesting 嵌套

建议看 《https://kentcdodds.com/blog/avoid-nesting-when-youre-testing》 这篇文件。

jest-in-case 和 test.each

如果你只是做纯函数的测试&＃xff0c;那么你很幸运&＃xff0c;因为它们都是最容易测的。你完全可以通过简单的抽象来简化测试代码&＃xff0c;让它们在调用时更明显地展示输入和输出内容。

比如&＃xff1a;

import add from &＃39;../add&＃39;test(&＃39;adds one and two to equal three&＃39;, () &＃61;> {expect(add(1, 2)).toBe(3)
})test(&＃39;adds three and four to equal seven&＃39;, () &＃61;> {expect(add(3, 4)).toBe(7)
})test(&＃39;adds one hundred and two to equal one hundred two&＃39;, () &＃61;> {expect(add(100, 2)).toBe(102)
})


我们还可以用 jest-in-case 更优雅的写法来实现&＃xff1a;

import cases from &＃39;jest-in-case&＃39;
import add from &＃39;../add&＃39;cases(&＃39;add&＃39;,({first, second, result}) &＃61;> {expect(add(first, second)).toBe(result)},[{first: 1, second: 2, result: 3},{first: 3, second: 4, result: 7},{first: 100, second: 2, result: 102},],
)


对这样简单的用例&＃xff0c;我可能不会用这样方式写&＃xff0c;不过&＃xff0c;能直接在数组后面添加输入和输出就能添加更多的测试用例&＃xff0c;感觉还是挺爽的。类似这类思路的一个很好的例子就是&＃xff1a;rtl-css-js 的测试用例。其它代码贡献者会发现用这样的结构来添加用例简直不要太爽&＃xff01;

当然这也可以用在一些非纯函数的情况&＃xff0c;不过可能要做更多的抽象了。&＃xff08;这有个例子&＃xff0c;虽然不是很好&＃xff0c;但是我觉得还凑合&＃xff09;

我个人是很喜欢 jest-in-case 的&＃xff0c;不过 jest 已经内置了 test.each 了&＃xff0c;应该会对你有所帮助。

总结

虽然我们的测试代码可以通过起更好的用例名&＃xff0c;写更多的注释来提升观感和可读性&＃xff0c;但是&＃xff0c;如果有一个简单的 setup 抽象函数&＃xff08;也叫做 Test Object Factory&＃xff09;&＃xff0c;就可以不需要它们了。所以&＃xff0c;我的观点是&＃xff1a;高质量且有意义的代码抽象能有效地减少编写和维护测试代码的成本。

好了&＃xff0c;这篇外文就给大家带到这里了。总的来说&＃xff0c;我是认可作者的观点的&＃xff0c;因为我们写单测时难免会遇到要构造一堆 Mock 对象、实例的情况&＃xff0c;而且对不同的测试用例 Mock 内容可能仅有细微差别。

而如果你把这些搞得太抽象&＃xff0c;比如放在 tests/utils 来生成对象的话&＃xff0c;又会导致太抽象而难以理解&＃xff0c;对阅读用例的人来说有着非常高的心智负担。所以最好的方式还是在当前测试文件中&＃xff0c;写一个 setup 函数来生成基础的 Mock 对象&＃xff0c;然后再在对应用例中做细微差别的调整即可&＃xff0c;并尽量把差异化展现出来。这不仅能让阅读者跟上用例的节奏&＃xff0c;也能对用例的输入和输出也一目了然。

如果你喜欢我的分享&＃xff0c;可以来一波一键三连&＃xff0c;点赞、在看就是我最大的动力&＃xff0c;比心 ❤️