设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
18805 人已学习
课程目录
已更新 31 讲 / 共 100 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (12讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
25 | 实战二(上):针对非业务的通用框架开发,如何做需求分析和设计?
26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (2讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册

28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?

王争 2020-01-06
上一节课中,我们对“为什么要重构、到底重构什么、什么时候重构、该如何重构”,做了概括性介绍,强调了重构的重要性,希望你建立持续重构意识,将重构作为开发的一部分来执行。
据我了解,很多程序员对重构这种做法还是非常认同的,面对项目中的烂代码,也想重构一下,但又担心重构之后出问题,出力不讨好。确实,如果你要重构的代码是别的同事开发的,你不是特别熟悉,在没有任何保障的情况下,重构引入 bug 的风险还是很大的。
那如何保证重构不出错呢?你需要熟练掌握各种设计原则、思想、模式,还需要对所重构的业务和代码有足够的了解。除了这些个人能力因素之外,最可落地执行、最有效的保证重构不出错的手段应该就是单元测试(Unit Testing)了。当重构完成之后,如果新的代码仍然能通过单元测试,那就说明代码原有逻辑的正确性未被破坏,原有的外部可见行为未变,符合上一节课中我们对重构的定义。
那今天我们就来学习一下单元测试。今天的内容主要包含这样几个内容:
什么是单元测试?
为什么要写单元测试?
如何编写单元测试?
如何在团队中推行单元测试?
话不多说,让我们现在就开始今天的学习吧!

什么是单元测试?

单元测试由研发工程师自己来编写,用来测试自己写的代码的正确性。我们常常将它跟集成测试放到一块来对比。单元测试相对于集成测试(Integration Testing)来说,测试的粒度更小一些。集成测试的测试对象是整个系统或者某个功能模块,比如测试用户注册、登录功能是否正常,是一种端到端(end to end)的测试。而单元测试的测试对象是类或者函数,用来测试一个类和函数是否都按照预期的逻辑执行。这是代码层级的测试。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(35)

  • 流年
    半年前,因为团队项目太多太乱已经很难维护和协作开发(10人的开发团队,每人负责一些项目,水平参差不齐,各自独立开发),作为团队中的资深者,我被leader要求开发一套通用的底层框架。

    为保证代码质量,刚开始时对自己要求严格,每个方法都必须要有多种case的单元测试;然后发现有时候写出来的单元测试代码比被测试的方法的代码量多很多,在一定程度上影响了开发速度。另外leader还经常安排我去修复一些仍在艰难运行的旧系统的故障(大多是累积下来的技术债),导致框架开发进展一再拖延。同时团队其他人很少有写单元测试代码,测试工作完全依赖测试人员完成,对自己也就逐渐放松了要求,单元测试不再追求完备,只在核心的方法中加入常规的实现逻辑测试,其他代码写完多看两遍确认无bug就提交。

    争哥的这节课程我完全理解,单元测试的重要性毋庸置疑,可是在实际开发过程中完全落实存在一定的困难,遇到这种问题我还真没啥解决的办法除了让自己拼命的加班,真的太难了。。。
    2020-01-06
    4
    17
  • 桂城老托尼
    感谢争哥分享,单元测试很重要,除此之外,集成用例和回归用例库同样重要,以及上线后的ab比对切流,这些在大厂其实都是落地了的常规武器。这里争哥没有提到。
    大厂之外,能落地的除了单测,还有简单的ab框架,集成平台自动化程度,否则一次重构下来非常耗费精力,而且还是冒着风险。
    另外,单测代码本身的质量也要有要求,tl要求单测代码和生产代码一样要遵守规范(视各厂情况定吧)。所以每次迭代开发测试时间比是1比2差不多了。 哭晕
    2020-01-06
    2
  • 李小四
    设计模式_28
    1. 有过一次失败的单元测试经验:好不容易申请到了2周的预研时间,我开开心心地研究怎么把JUnit引入项目,刚开始了两天,新的开发任务打断了我的计划,然后就再也没有继续了。。。

    2.
    代码:
    /**
     * 查找递增数组中第一个大于等于某个给定值的元素
     * @return -1: 未找到
     */
    public int findFirstEqualOrLargerIndex(int[] array, int num) {
        if (array == null || array.length == 0) return -1;

        int start = 0;
        int end = array.length - 1;

        while (start != end) {
            int middle = start + (end - start) / 2;

            if (array[middle] >= num) {
                if (start == middle) return middle;
                else
                    if (array[middle - 1] < num) return middle;
                    else end = middle -1;

            } else {
                start = middle + 1;
            }
        }
        //start == end
        if (array[start] >= num) {
            return start;
        } else {
            return -1;
        }
    }

    测试用例:
    findFirstEqualOrLargerIndex(null, 1)
    findFirstEqualOrLargerIndex(new int [0], 1)
    findFirstEqualOrLargerIndex(new int [] {0}, 1)
    findFirstEqualOrLargerIndex(new int [] {1}, 1)
    findFirstEqualOrLargerIndex(new int [] {0, 0}, 1)
    findFirstEqualOrLargerIndex(new int [] {0, 1}, 1)
    findFirstEqualOrLargerIndex(new int [] {1, 1}, 1)
    findFirstEqualOrLargerIndex(new int [] {0, 1, 2}, 1)
    findFirstEqualOrLargerIndex(new int [] {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}, 1)
    findFirstEqualOrLargerIndex(new int [] {0, 1, 1, 1, 1, 1, 6, 7, 8, 9}, 1)
    findFirstEqualOrLargerIndex(new int [] {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}, 10)

    我估计应该有漏洞,请老师和同学们指正~
    2020-01-06
    7
    2
  • 辣么大
    关于问题2,尝试写了一下单元测试:
    https://github.com/gdhucoder/Algorithms4/tree/master/designpattern/u28
    2020-01-06
    2
  • 逍遥思
    独立开发者,项目代码量 10W 行以内,在可以预见的未来不会超过 20W 行
    以前试过 git 各种最佳实践,最后发现一个分支基本就够用了
    所以还是忍不住想问问老师,如果项目真没那么大,是否需要单元测试?
    2020-01-06
    4
    1
  • 黄林晴
    打卡✔
    我觉得写单元测试的难点是覆盖测试用例
    我们出的bug 不都是没考虑特殊情况吗,如果单元测试可以想到全部的测试用例,代码有bug 的可能性应该不大
    2020-01-06
    1
    1
  • 再见孙悟空
    确实单元测试只在一开始才写过,后来发现拖慢了开发的进度,就渐渐放弃了,现在我们的开发团队里几乎没什么单元测试,除非一些涉及到优惠券,订单奖励计算等和钱挂钩的业务,我觉得一方面是因为消耗时间,另一方面业务代码没写好,很多时候很不利于进行单测,要造各种数据。我觉得单测最好是在开发一个方法或者函数之后就进行,且要在测试介入之前,否则测试介入以后再补充单元测试,有可能会改动到已写好的业务,那么就又需要回归测试一遍,对开发,测试都是很消耗的。
    2020-01-06
    1
  • 我感觉我写单测最大的问题在于很难把代码写成那种细粒度可测的模样,而不是要去写。
    2020-01-06
    1
  • leon
    坐标阿里,周边同事几乎没有写单元测试的习惯,就算写也只是为了测试当前版本的功能,而不是为了以后迭代和重构。
    很可悲
    2020-01-06
    4
    1
  • 张迪
    写单元测试就是不知道如何命名单元测试的方法名,有时候这个方法都不知道如何描述好,
    2020-01-07
  • Frank
    以前在开发中,没有写单元测试的意识。开发完功能后,直接去测试一个完整的流程。即前端发请求,服务端处理,看数据库数据。如果功能正确就过。这是从一个功能宏观去考虑测试。而单元测试是更细粒度的测试,它在保证各个“单元”都测试通过的情况下整个功能模块就测试通过了。这样的方式对于我们自己来说对代码可控粒度更细。更能比较清楚的理解某个“单元”在整个功能模块调用链路上的位置,承担什么职责,以及有什么行为。而不是一开始就站在模块宏观角度来思考。通过一个个单元测试的编写,将整个功能模块串联起来,最终达到整个功能模块的全局认知。 这也体现了任务分解的思想。通过单元测试,可以从另外一方面实现对已编写的代码的CodeReview,重新梳理流程。也为以后有重构需求打下基础。
           目前参与的项目中有单元测试,但是不够完备。可能由于某些原因(开发人员意识问题,团队对单元测试的执行落地程度不够等)。在写单元测试的过程中,遇到单元测试依赖数据库查询问题,因为存在多套环境,如开发环境,仿真环境,线上环境。对于依赖数据查询的单元测试,只能自己造假数据来解决。不知道还有什么好的解决办法。
    2020-01-06
  • DullBird
    刚开始接触单元测试的时候。会编写完整的单元测试,但是当时接触的是CURD的接口,比如根据条件批量查询符合条件的员工的一个service接口,然后部分数据通过缓存,部分数据通过db组合在一起,比如调用cacheManager + UserMapper,测试这个接口就需要mock cacheManager和UserMapper,导致代码测试起来比较麻烦,大量时间花在编写mock对象,但是其实和这个接口对外的功能又没关系,是内部的实现逻辑有关系。这一点比较疑惑,觉得这样测试已经违背了理解代码内部逻辑的原则,但是不构造这些异常,这个接口又没什么好测试的,对于代码的可测试性的概念,如何提升可测试性,还是模糊的。
    后面虽然没有坚持写完整的单元测试了,但是程序的正确性流程。还是会编写单元测试走走一遍。
    2020-01-06
  • 平风造雨
    https://github.com/zhangw/misc.java.jimohou.me/blob/master/src/test/java/test/geekbang/design/pattern/beauty/artical28/HomeWorkTest.java
    2020-01-06
  • 刘大明
    说起来真的是难受。整个项目中就我一个人写单元测试。每次做的功能都有单元测试覆盖。而且项目中junit包都是我导入的。更加奇葩的是我的功能单元测试领导还不让我提交。说是你的测试代码为什么要提交,我瞬间无语了。
    2020-01-06
  • 七楼
    单元测试 让我的逻辑更缜密了 的确有好处 而且bug也少
    2020-01-06
  • Jeff.Smile
    程序员这一行业本该是智力密集型的,但现在很多公司把它搞成劳动密集型的。
    ——————————————————
    你这句话道出了现实!哈哈😄
    2020-01-06
    1
  • Arthur.Li
    项目越来越大,和复杂化,每次新增功能或者改造测试都很麻烦,还容易测试不到。就是单元测试不够,今年目标是把核心功能加上单元测试,估计能节省大量的测试时间。
    单元测试能检验代码好坏,是不是高耦合,确实,如果不重构,单元测试都没法写了。
    2020-01-06
  • yaomon
    程序员这一行业本该是智力密集型的,但现在很多公司把它搞成劳动密集型的,包括一些大厂,在开发过程中,既没有单元测试,也没有 Code Review 流程。即便有,做的也是差强人意。
    ----------------------------------------------------------------------------------------
    差强人意:指尚能使人满意。根据文章上文,明显是不能使人满意的意思。处理为语病。

    编辑回复: 差强人意是勉强使人满意,不是十分使人满意。所以这里没问题呢~

    2020-01-06
  • Jamespxy
    单元测试大法好,知易行难!
    2020-01-06
  • Jxin
    1.tdd是以终为始的开发模式。即先确定好验收标准,再根据标准去开发。如此一来设计出来的代码跟验收标准能更好的关联。至于单元测试,单元测试的case与tdd的终并不是直接一一对应的,但也可以算是一个终拆解出来的细力度的子终。但单元测试是实现层面的自检方案,tdd是设计层面的衡量指标,感觉是两个层面的概念,形似而神不同。

    2.我接手的项目,没几行单元测试,且年久失修也基本全部无用。起初也是坚守写单元测试,补充涉及到的业务的单元测试。但坚持补了40%左右后也就放弃了。原因,1.补别人的测试用例太耗时,而且不全面(短时间了解并不透彻,也不该花太多时间都了解透彻)。2.个中价值不被认可(在一个快糙猛的大环境下,逆行总归异类。你可以接受额外的加班,但很难在他人评价上坚守初心)3.事出必有因,快糙猛也没有错,毕竟技术债务这东西是可以不还的(遗憾的是,有利可图时还不知道还债,硬是要债高难还时再推倒重做)。
    2020-01-06
收起评论
35
返回
顶部