知乎大 V 李松蔚讲了个和女儿互动的故事,很有意思:
我关上灯,对女儿说:「闭上眼睛,别乱动了。」
女儿立刻大声抗议:「可是我睡不着!」
我只好又强调了一遍:「我只是请你闭上眼睛,别乱动。」
-- 李松蔚 《忍受简单的能力》
他并没有要求女儿「尽快睡着」,而是做了个更简单的要求;但是聪明的女儿立刻联想到了「即使闭上眼睛现在也睡不着」并做出抗议。
在这篇文章里,他说:「对于聪明人来说,最难以忍受的情况不是一件事有多难,而是纯粹的简单」,「没有难度挑战的任务,会让他们感到无所着力」,「重复的练习是他们的死穴」。
单元测试似乎就是一种「简单而重复」的过程,不论是看起来还是写起来,都是由一大堆 GIVEN - WHEN - THEN 组成。
但是这「简单」的表象之下,隐藏着两个「简单」却很重要的问题:
按照套路,接下来应该先说「为什么要写单测」,但是太套路就有点无聊,所以咱们先聊聊「如何写好单测」。
所谓面条式代码( spaghetti code ),是说某段代码和意大利面(不是通心粉)一样。
反正不是什么好话。
最近看到这么一段代码,功能是创建某个月的值班记录:
def onduty(names):
date = datetime.strptime("2021-07-01", "%Y-%m-%d")
idx = 0
while date < datetime.strptime("2021-07-31", "%Y-%m-%d"):
post_data = {
"date": date.strftime("%Y-%m-%d"),
"name": names[idx],
"backup": names[(idx+1)%len(names)],
}
requests.post(API_URL, json=post_data)
idx = (idx + 1) % len(names)
date += timedelta(days=1)
注:原代码有 60 行,这里略作简化。
这是一段典型的「逻辑很齐全,但是 un 单测 able 」的代码:
那么应该如何为它写单测呢?
如果一段代码不好写单测,说明它的代码结构有问题。
-- 鲁迅《我没说过这句话》
对于结构有问题的代码,首先要做的显然是重构。
我们首先关注这段代码的主要问题:调用「 requests.post 」请求了外部系统,这导致它和外部系统耦合在一起。
一个很容易想到的思路是,通过依赖注入的方式来解耦:
def onduty(names, saver)
...
saver(post_data)
...
这样简单的改造以后,它就变成了一段「单测 able 」的代码了:通过 mock 一个 saver,我们可以采集并校验它的输出,例如
class Saver(object):
def __init__(self):
self.output = []
def mocker(self):
def f(post_data):
self.output.append(post_data)
return f
def test():
f = Saver()
onduty(['a', 'b', 'c'], f.mocker())
check(f.output)
但是这样写出来的代码非常晦涩。更合理的方法是,将这段逻辑拆分成「生成值班列表」和「上报到值班系统」:
def onduty(names):
arrangement = arrange(names)
register(arrangement)
然后我们就可以将「生成值班列表」实现成一个纯函数:
def arrange(names):
arrangement = []
date = datetime.strptime("2021-07-01", "%Y-%m-%d")
idx = 0
while date < datetime.strptime("2021-07-31", "%Y-%m-%d"):
arrangement.append({
"date": date.strftime("%Y-%m-%d"),
"name": names[idx],
"backup": names[(idx+1)%len(names)],
})
idx = (idx + 1) % len(names)
date += timedelta(days=1)
return arrangement
就像数学课上的 y = f(x)
,不产生任何副作用,于是我们可以非常容易地给 arrange
方法写单测:
def TestArrage():
// Given
names = ['a', 'b', 'c']
// When
arrangement = arrange(names)
// Then
check(arrangment)
「上报到值班系统」的实现就像这样:
def register(arrangement):
for item in arrangement:
requests.post(API_URL, item)
因为涉及到外部系统,确实不太适合写单测,更适合用功能测试来保障其正确性。
另外,因为在 arrange
里硬编码了两个日期,单测的校验逻辑会非常繁琐,我们可以再对其进行重构,把日期作为参数输入:
def arrange(names, from_date, to_date):
...
这样使得代码的职责更明确,不但可以提高这段代码的复用性,还可以对更特别的 case (例如大小月、闰年等)做校验。
小结一下:
当然,以上只是一个简单的例子,并不是完整的单测方法论。实践中还有很多其他环节需要考虑:
感兴趣的同学可以参考腾讯技术工程的《聊聊单元测试那些事儿》。
通过上面的一番骚操作,我们已经看到了单测的好处:
而比重构现有代码更重要的是:
当然,刚开始实践单测的同学可能会感受到,这降低了编码的速度;
但是经过一段时间的重复练习,这种思维会被内化,自然地就能写出高质量的代码。
在实践中,单测实际上也大幅提高了测试的效率。
构造一个完整的测试往往是很耗时的,编译 1 分钟、启动 1 分钟,发个测试请求 1 秒钟,「性价比」很低(这可能是很多同学不喜欢测试的原因)。
而单测只需要编译运行少部分代码,因此可以快速验证代码逻辑。
由于大量代码 bug 在单测时就已经被发现并修复了,可以大幅减少后续 “修改 - 编译 - 启动 - 测试” 环节的数量,这也极大提高了整体的测试效率。
在《聊聊单元测试那些事儿》里还有一份微软的数据:
不同测试阶段发现 BUG 的平均耗时:
- 单元测试阶段,平均耗时 3.25 小时
- 集成测试阶段,平均耗时 6.25 小时 (+92%)
- 系统测试阶段,平均耗时 11.5 小时 (+254%)
最近遇到的一个 case 也是很好的例子:手头项目多版本并行,我在 A 版本开发的功能,需要 merge 到 B 版本,merge 以后,跑了一轮 test case,就可以比较放心地说,merge 后的代码没有问题 ——
同样地,当我们需要给一段代码添加新功能时,如果有存量的 unit test,我就可以比较放心地去修改它了。
在《忍受简单的能力》里,李松蔚说:
所以我认识的学生里面,除了少部分天赋异禀的奇才之外,真正最影响一个人的成就的因素,可能不是智商,也不是努力,而在于他有多「踏实」。
写高质量的代码,从踏实地写单测开始。
btw,李松蔚这篇文章实在太经典,我忍不住要再引用一段:
一口一口地吃饭太慢了。恨不得一口吃下一百口,谁叫锅里还有那么多? 所以重要的事情才要说三遍。可是上一段让你看了三遍的话是什么,你还记得吗?
如果不记得的话,可以试试下面这句:
加入神策数据,帮助客户实现数据驱动。
加入神策数据,帮助客户实现数据驱动。
加入神策数据,帮助客户实现数据驱动。
神策数据是一家致力于“帮助三千万企业重构数据根基,实现数字化经营”的大数据公司。公司正在飞速发展,在北京、上海、武汉、成都、西安、合肥等地都有研发中心,后端、前端、客户端、QA 等岗位均虚位以待,对大数据感兴趣的同学千万不要错过 ——
▄▄▄▄▄▄▄ ▄ ▄▄▄▄ ▄▄▄▄▄▄▄
█ ▄▄▄ █ ▄▀ ▄ ▀██▄ ▀█▄ █ ▄▄▄ █
█ ███ █ █ █ █▀▀▀█▀ █ ███ █
█▄▄▄▄▄█ ▄ █▀█ █▀█ ▄▀█ █▄▄▄▄▄█
▄▄▄ ▄▄▄▄█ ▀▄█▀▀▀█ ▄█▄▄ ▄
▄█▄▄▄▄▄▀▄▀▄██ ▀ ▄ █▀▄▄▀▄▄█
█ █▀▄▀▄▄▀▀█▄▀█▄▀█████▀█▀▀█ █▄
▀▀ █▄██▄█▀ █ ▀█▀ ▀█▀ ▄▀▀▄█
█▀ ▀ ▄▄▄▄▄▄▀▄██ █ ▄████▀▀ █▄
▄▀▄▄▄ ▄ ▀▀▄████▀█▀ ▀ █▄▄▄▀▄█
▄▀▀██▄▄ █▀▄▀█▀▀ █▀ ▄▄▄██▀ ▀
▄▄▄▄▄▄▄ █ █▀ ▀▀ ▄██ ▄ █▄▀██
█ ▄▄▄ █ █▄ ▀▄▀ ▀██ █▄▄▄█▄ ▀
█ ███ █ ▄ ███▀▀▀█▄ █▀▄ ██▄ ▀█
█▄▄▄▄▄█ ██ ▄█▀█ █ ▀██▄▄▄ █▄
1
peacelove 2021-09-09 10:21:03 +08:00 via iPhone
这么长的文章,我一般先拉到最后…
|
2
yolee599 2021-09-09 10:21:43 +08:00
直接拉到最后,果然是一个二维码
|
3
cloudfox 2021-09-09 10:28:44 +08:00
字符二维码有点骚,不过扫不出来
|
4
nockyQ 2021-09-09 10:30:26 +08:00 1
深以为然。足够多的单元测试不仅能对项目的 QC 做出贡献,还能像说明文档一样帮助其他成员理解具体的代码功能。是非常有意义的工作。
|
6
Wincer 2021-09-09 10:40:23 +08:00
楼主之前发的帖子内推都是头条,这次跳槽了?
|
7
nickr 2021-09-09 10:49:42 +08:00
ascii 二维码很酷. 可以扫出来.
可能和字体有关. mac+safari 上没问题. |
8
Glauben 2021-09-09 11:06:10 +08:00
有一说一,虽然后面有广告,但文章的内容还是很不错的
|
9
via 2021-09-09 12:14:31 +08:00 via iPhone
我用 py,理所当然所有人都应当用 py 。
|
10
jie170601 2021-09-09 12:50:40 +08:00 via Android
感谢,看完有收获的,关于单测,最纠结的还是带 IO 的代码要不要测,似乎还没个定论
|
12
bytesfold 2021-09-09 13:51:29 +08:00
带 IO 的怎么测试,例如串口
|
13
shyrock 2021-09-09 14:25:14 +08:00
知道单测理论并认同单测有价值的人占程序员总数 85%;真正在工作中执行单测的人占比有多少?
|
14
rioshikelong121 2021-09-09 15:51:39 +08:00
看时间给的够不够了
|
15
42is42is42 2021-09-09 17:12:23 +08:00
Unit testing won’t help you write good code.
|
16
zzlit 2021-09-09 17:18:06 +08:00
正好借楼问一句 mocha 不借助 karma 如何才能有浏览器里面 window 的这个参数?就像这个[问答]( https://stackoverflow.com/questions/41194264/mocha-react-navigator-is-not-defined)我加了 jsdom 也还是不行
|
18
felix021 OP @bytesfold 参考 11L,文中也说了( register 方法),副作用本身没法用单测来做,单测能做的事情是,在把副作用剥离出来(依赖注入、mock )的前提下,验证其他逻辑的正确性。
|
20
otakustay 2021-09-09 18:30:49 +08:00 3
@42is42is42 但是 UT 在把 ugly code 往 good code 重构的过程中作用非常非常的大,只要有对 good code 的追求,UT 就是最好的武器
|
22
timethinker 2021-09-10 16:11:40 +08:00 2
对我而言,单元测试提高了团队成员的自信,放下了悬在心中的那块石头,不用担心每一次修改是否会破坏某些东西而诚惶诚恐。
|
23
lei2j 2021-09-10 18:04:36 +08:00
尼玛,拉出来一个二维码
|
24
chaleaoch 2021-09-21 00:54:07 +08:00
谢谢, 学到很多.
|
25
chaleaoch 2021-09-21 00:55:47 +08:00
另外, 那个依赖注入的方式真的好吗?
看起来确实影响了原业务的编写. 为了单元测试这个目的, 整个项目会增加很多的回调啊. 但是在"聊聊单元测试那些事儿" 这篇文章中, 却看到 这种方式实际上还有一个概念叫"打桩". 那么一定有很多项目是通过这种方式实现的单元测试了? 大佬能够针对这一点进行一些指点. 谢谢. |
26
felix021 OP @chaleaoch 依赖注入是比较常见的解耦方式,也就是我们常说的「面向接口编程」,在 Java 生态里常见的做法是通过 Bean 的属性注入,写起来会容易一点。
|