Day 04 「树头顾乎哉」测试金字塔 之 Unit Test v.s. Integration Test

今天先来聊聊测试的规模与边界。

测试金字塔

说到单元测试,那就一定要提到 Mike Cohn 在书中提到,有名的「测试金字塔」:


图片转自 Martin Fowler 的部落格

Mike Cohn 认为,一个健康的系统,所包含的测试可以包罗万象,但是单元测试应该要占最大篇幅,而整合度最大的 UI 测试应该要最少。

从速度的角度来看,笔者认为很合理,因为 Unit Test 执行速度快,包含范围小,所以可以在最短时间,验证最多功能,要新增或修改也很灵活。UI 本身就是一个很常修改的东西,而且测试成本高,所以如果太多测试建立在 UI 之上,那麽动辄得咎,会花很多成本在修改测试,但却只是为了一个「与正确性无关,只是美观上有差」的修改。因小失大。

Unit Test 与 Integration Test

到底「整合测试」的定义是什麽?跟「单元测试」有什麽区别?他等於是测试金字塔里的 Service Test 吗?其实这个问题,笔者认为非常难回答,连 Martin Fowler 与其他几位大师级人物也常有讨论。以下摘录 Martin Fowler 部落格里的一段话(但作者是 Ham Vocke):

Unfortunately the concept of the test pyramid falls a little short... Some argue that either the naming or some conceptual aspects of Mike Cohn's test pyramid are not ideal...Your best bet is to remember two things from Cohn's original test pyramid:

  1. Write tests with different granularity
  2. The more high-level you get the fewer tests you should have

Stick to the pyramid shape... Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end... don't end up with a test ice-cream cone...Don't become too attached to the names of the individual layers in Cohn's test pyramid...

笔者刻意删除一些文字,希望能够凸显较重要的意图,如读者依旧对全文有兴趣,请见此连结

Martin Folwer 希望我们要抓紧的是测试金字塔的「形状」,抓紧「低阶测试多一点、高阶测试少一点」的原则,而不用太过计较用字遣词与各层的界线与定义。他认为我们只要努力避免反模式「测试甜筒」的出现,其实就可以将低测试的成本,并提高易修改性。

Kuma 怎麽看

其实笔者一直是很不喜欢做 UI 测试与「跨系统整合测试」的人。我常常听很多朋友说他们公司「单元测试做得很少,整合测试做很多,而且是真的有存取 DB 的那种」。我是可以理解原因啦,因为这种测试一开始的确是比较好写,而且透过坊间一些框架的帮忙,甚至可以不用写 code,就能达到效果,并且具有一定的保护力。

然而,这当中其实有很多是在开发时,靠单元测试就能找到的问题。在单元测试就抓到问题的话,修复成本其实比较便宜。再者,如前所述,单元测试其实是功能的一部份。如果单元测试品质够好,自然能建立大家对功能本身的信心,那麽,较高阶的测试就可以不用做这麽多,就有一些论述认为,在此前提下,一定阶层以上的测试,可以只测「Happy Path」就好。

再者,单元测试的一个测试牵扯范围都不大,所以一旦需求有改,改单元测试也比较灵活。这点,我认为写测试跟写程序是一样的,当需求变更,我们不需要做到「完全不用修改」,只要做到「改动不会太大」,啊跑测试不要太久,这样就好了。

谜之声:「名字什麽的不重要,高低阶测试的比重抓准就好。」

Reference

  1. Martin Fowler 部落格:https://martinfowler.com/articles/practical-test-pyramid.html
  2. Mike Cohn 部落格:https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
tags: ithelp2021

<<:  开启Python IDLE

>>:  Day 4 - 虚拟机的设置

day 26 - 如何知道我交出了一个有品质的系统

这几天纪录下开发流程中可能会考量的项目跟使用工具纪录, 在开发完成到系统交付之後, 又是另一个阶段的...

【Day 4】物理时间、happens-before 关系、causality

回家再修文,先发ㄌ 晚点要补一下前一篇的 failure detectors 介绍分散式系统中的时间...

Day02 - GCP 介绍及环境建置

什麽是云端服务 ? 云端服务指的就是将软硬体等资源,放到网际网路上作为服务,使用者只需透过网路,就可...

[D09] still placeholder

写在前面 still placeholder still placeholder still pla...

【Day 12】使用 Systems Manager 的 Parameter Store 保存变数

tags: 铁人赛 CodeBuild AWS SSM 前言 关於 Developer Tool -...