首页 文章详情

Go Test: 从入门到躺平

GoCN | 34 2022-08-26 16:33 0 0 0
UniSMS (合一短信)

单元测试通常是由软件开发人员编写和运行的自动测试,以确保应用程序的某个部分(称为“单元”)符合其设计并按预期运行。在过程式编程中,一个单元可以是一个完整的模块,但它更常见的是一个单独的函数或过程。在面向对象的编程中,单元通常是整个接口,例如类或单个方法。通过首先为最小的可测试单元编写测试,然后为它们之间的复合行为编写测试,可以为复杂的应用程序建立全面的测试。


在开发过程中,软件开发人员可能会将标准或已知良好的结果编码到测试中,以验证单元的正确性。在测试用例执行期间,框架会记录不符合任何条件的测试,并在摘要中报告这些测试。为此,最常用的方法是测试 - 函数 - 期望值。


### 好处


单元测试的目标是隔离程序的每个部分,并表明各个部分是正确的。单元测试提供了一个严格的书面契约,你实现的代码逻辑单元必须满足这个契约。因此,它提供了几个好处。


- 早期发现问题:单元测试在开发周期的早期发现问题。这包括程序员实现中的错误和单元规范的缺陷或缺失部分。编写一组完整的测试的过程迫使作者仔细考虑输入,输出和错误条件,从而更清晰地定义单元的所需行为。在编码开始之前或首次编写代码时查找 Bug 的成本远低于以后检测、识别和更正 Bug 的成本。已发布代码中的错误也可能给软件的最终用户带来代价高昂的问题。如果写得不好,代码可能不可能或难以进行单元测试,因此单元测试可以迫使开发人员以更好的方式构建函数和对象。

  

- 适合敏捷编程:测试驱动开发(TDD)经常用于极限编程和Scrum,它要求单元测试是在编写代码本身之前创建的。测试通过后,该代码将被视为已完成。如果单元测试失败,则将其视为已更改代码或测试本身中的 Bug。然后,单元测试允许轻松跟踪故障或故障的位置。由于单元测试在将代码交给测试人员或客户端之前会向开发团队发出问题警报,因此在开发过程的早期会发现潜在的问题。

  

- 适合回归测试: 单元测试允许程序员在以后重构代码或升级系统库,并确保模块仍然正常工作(例如,在回归测试中)。该过程是为所有函数和方法编写测试用例,以便每当更改导致错误时,都可以快速识别它。单元测试检测可能破坏设计合同的更改。

  

- 确保单元稳定:单元测试可以减少单元本身的不确定性,并且可以用于自下而上的测试样式方法。通过首先测试程序的各个部分,然后测试其各部分的总和,集成测试变得更加容易。

  

- 单元测试就是"文档":单元测试提供了一种系统的活文档。希望了解单元提供哪些功能以及如何使用它的开发人员可以查看单元测试,以基本了解单元的接口 (API)。

  


### 局限性和缺点


- 测试不会捕获程序中的每个错误,因为它无法覆盖程序中的每个执行路径。

  

- 单元测试的详细层次结构不等于集成测试。与外围单元的集成应包含在集成测试中,但不应包含在单元测试中。

  

- 软件测试是一个组合问题。例如,每个布尔决策语句至少需要两个检验:一个结果为“true”,另一个结果为“false”。因此,对于编写的每行代码,程序员通常需要3到5行测试代码。这显然需要时间,收益可能和投入不成正比。

  

- 有些场景不容易测试。例如那些非确定性或涉及多个线程的问题。此外,单元测试的代码与它正在测试的代码一样可能存在错误。

  

- 流程和规范也很重要,规范的制度确保定期审查测试用例失败并立即解决。如果这样的过程没有被实现并根深蒂固地融入到团队的工作流程中,应用程序将与单元测试套件不同步,增加误报并降低测试套件的有效性。

  


单元测试最初兴起于敏捷社区。1997年,设计模式四巨头之一Erich Gamma(设计模式、Junit、Eclipse、VSCode)和极限编程发明人Kent Beck(极限编程、测试驱动开发、JUnit)共同开发了JUnit,而JUnit框架在此之后又引领了xUnit家族的发展,深刻的影响着单元测试在各种编程语言中的普及。当前,单元测试也成了敏捷开发流行以来的现代软件开发中必不可少的工具之一。同时,越来越多的互联网行业推崇自动化测试的概念,作为自动化测试的重要组成部分,单元测试是一种经济合理的回归测试手段,在当前敏捷开发的迭代中非常流行和需要。


二十年前,单元测试的方法和JUnit引入到国内的时候,大家都是求知若渴,将其奉为圭臬。不幸的是,在当前一个浮躁的追求短期利益的互联网时代,很多公司甚至头部大厂都已经不把单元测试作为提升软件质量的一种手段,甚至几乎不写单元测试了。“能逮着老鼠的就是好猫”成了大家衡量成功的标准,糙快猛的把原型堆出来,原型试错,快速拿奖走人大行其道。万幸的是,在一些公司中,还是有一些工程师,依然坚持着传统的信念,不会把“时间紧需要快速出活”作为理由降低代码质量,还是把单元测试、代码规范等坚持下来。


即使现在有些公司,采用tcpcopy、goreplay复制线上流量对测试环境的系统进行测试,或者像滴滴的[写轮眼](https://github.com/didi/sharingan)可以在一定程度上解决手工编写测试的麻烦以及微服务依赖的问题,但是它们更多的是复制线上流量对集成系统所做的正面测试,对于单元测试的全面覆盖、尤其是测试路径的全面性包括负面测试还需要单元测试去实现。当然还有一些通过历史数据进行单元测试的一些方法也是类似。


有些同学已经了解了Go Test的基本写法,还想进一步了解Go Test的各个方面,我特意编写了一本《Go Test: 从入门到躺平》的电子书,帮助大家全面了解Go Test方方面面。你可以从github下载此电子书: 


https://github.com/smallnest/go_test_workshop/blob/master/Go%20Test%20%E4%BB%8E%E5%85%A5%E9%97%A8%E5%88%B0%E8%BA%BA%E5%B9%B3.pdf



2022 GopherChina大会报名火热进行中!
扫描下方二维码即可报名参与

大会合作、现场招聘及企业购票等事宜请联系微信:18516100522

戳这里上车!

good-icon 0
favorite-icon 0
收藏
回复数量: 0
    暂无评论~~
    Ctrl+Enter