当我们谈论Unit Test时我们在谈论什么？

原创文章，转载请注明出处

作为一个实际写代码的Coder，老代码能不碰就不碰---我举双手赞成，既没有UT，逻辑又混在一起，天知道改完以后会出什么Bug。
但是对于团队来讲，如果明确知道这个模块无法测试、无法被很好的修改，那么是时候把这部分代码提上重构的日程了。

一. 什么是Unit Test

直译：面向独立单元的测试方法。
单单这一句话我们心里有就有了疑问：什么是独立单元，或者什么样的代码才算一个独立单元？
为了回答这个问题，这里引用一下wikipedia的解释：

Intuitively, one can view a unit as the smallest testable part of an application.
https://en.wikipedia.org/wiki/Unit_testing

我们来抓一下重点：

1. 单元，对于不同的编程语言，单元的定义并不相同。在面向过程的语言中（C等），单元通常被定义为一个函数(Function)；而在面向对象的编程语言中(Java等)，单元往往指一个类（也可指代具体的方法Method）。
2. 最小的，小到无法再拆分，这个单元只做了一件事。
3. 可测试的，这个单元应该有明确的输入和输出，并且在输入确定时，我们应该能够预测输出的情况。

二. Unit Test要达到的目标

从工程师的角度来看，一些童鞋可能会觉得写Unit Test是枯燥切无意义的。工程期就那么几天，产品经理又不停的改功能，哪有心情和时间来写UT？
这种想法可以说对也可以说不对。首先，面对有限的时间和变动的需求，为所有代码写UT是不现实的。但是不是UT就真的是枯燥且无意义的呢---也不是。至少从我的角度来看，一个项目的UT需要起到以下三个作用。

• 检查出明显的Bug
• 为如何使用函数（单元）提供样例
• 为了重构

可能有人会说，为了检查Bug，这不废话吗。。。当然我相信在座的各位对于如何在UT中检查Bug都有两把刷子的，而这恰好也不是我想讨论的重点，但我们还是需要注意：UT并不能检查出所有Bug，对于无法预知的用户输入，UT能做的只是在我们所考虑到的情况下，避免一些明显的错误。但是对我们没有考虑到的情况-----告辞。。。
这里着重讨论一下后面两点：

1. 提供样例，有的童鞋习惯在函数上面写上一大段的注释，有时候看业务代码搞得像在读JDK源码。出现这种情况，我认为可能有两个原因：
   第一，代码没有做好拆分工作，将过多的逻辑糅合在一个类（方法）中，需要考虑的输入情况异常多，直观上根本无从下手来写UT。
   针对这种情况，我们应该考虑使用一些设计手法将代码拆分成独立的可测试的最小单元。
   第二，这个单元已经是最小的了，但是它确实有许多逻辑需要处理。首先，我认为如果真的拆分成了最小单元，那需要处理的逻辑应该并不会太多，至少不需要写一段话来描述它要做的事情。即使需要告知后来的开发这里做了什么，一个完整的UT也比阅读一大段文字来的实际。

2. 为了重构
   许多工程师对重构这个词有个错误的印象---提到重构，我们就需要对代码做翻天覆地的变化，甚至觉得是把以前的代码废弃掉重新写。
   最近阅读了一些重构方面的书籍，有一个让我印象深刻的观点：重构应该要贯穿整个产品的生命周期。有因为业务扩展与变动进行重构，也有一个Bug导致需要对代码结构进行重构。而但凡涉及到重构，我们就需要UT为我们保驾护航。
   在对代码进行重构时，UT就像一张保护网，防止我们破坏掉原有的逻辑。对于一个规模不大的核心模块，在上线之初我们就为它编写了详细的UT用例，使其满足我们所考虑的各种情况。但是随着业务的增长，我们可能需要对模块内部进行优化，使其有更高的性能。得益于我们之前的工作，每重构完一段代码，我们都运行一遍UT，如果通过，大概率说明我们没有“搞破坏”。当整个部分重构完成，我们需要反过来对UT进行审视，之前没有考虑到的情况、新的代码都需要进行覆盖。
   这样我们的代码保护网就会越来越牢固。可以想象，如果没有UT，我们新来的开发人员在修改老功能时是多么的紧张，因为他不知道自己也许不经意间破坏了原有的逻辑。

三. 哪些地方需要Unit Test

正如前文所述，并不是所有地方都需要写UT，从某种意义上讲，UT应该越少越好，前提是系统拆分够精确，关注点的测试够详细。
针对实际的项目，我对代码进行了一些分类：

1. 琐碎的代码，例如getter/setter,toString。除非有特殊逻辑，否则为这些代码写UT没有意义。
2. 无明确意义、承上启下的代码，例如一些只做透传作用的Service等。（当然，个人认为这种只做透传的代码应该尽量少）
3. 具有算法和业务逻辑的代码。这部分代码我们应该重点关注，最为典型的就是一些公共类，基础Service层等。尽量为它们写上详尽的UT，造福后人。
4. 最后一类是非常复杂的代码。各种复杂逻辑交织在一起，牵一发而动全身，我们本能地可以感觉到代码中的“坏味道”。对于这类代码，首先应该考虑做代码的清理工作（由粗到细重构），过程中不断为小单元注入Unit Test，最后形成一张严密的代码保护网，将原来的代码切碎为可维护的代码。

在实际开发中对第四点可能有些争议。对于公司或者团队来讲，一个产品的代码不可能始终是一个人负责，但往往新的同事接手老代码时不知道从哪下手。我的第一份工作，当我作为一个毕业生，第一次接手一个完整的项目代码，一上来就是一个好几千行的函数，其中包含的各种请求的发送，变量的随意命名与重复使用，还有各种复制粘贴的痕迹。你能想象对于一个新人来讲这是多么的绝望吗。
作为一个实际写代码的Coder，老代码能不碰就不碰---我举双手赞成，既没有UT，逻辑又混在一起，天知道改完以后会出什么Bug。
但是对于团队来讲，如果明确知道这个模块无法测试、无法被很好的修改，那么是时候把这部分代码提上重构的日程了。

其实我认为代码的组织与规范（包括UT）是开发流程中非常重要的一部分，在一开始我们就应该定期进行CodeReview，避免写出无法维护的代码。一个团队可能会负责多个项目，这些项目应该是属于团队中的每一个人，而不是谁负责，其他人就可以不管。我们应该把项目的Dev和Ops视为自己的责任。有太多的项目由于走形式的CodeReview、没有UT、没有文档，导致最后无法维护，这是我们都不想看到的。

UT是不可能写的，这辈子都不可能写的，老代码就只能让它勉强运行下去这样子~

四. 怎么做Unit Test

至于如何做UT，网上一搜一大把的教程，这里就不赘述了，只是列几条个人总结的值得注意的点：

• 多组数据（考虑周全）->正常业务测试，边界条件测试
• 不要误用Mock工具，理清需要被Mock的对象
• 整体覆盖率没有意义，但是关键业务代码覆盖率很重要
• 运维时：每一个BugReport都应有一个对应的UT
• UT并不是越多越好，而是对于核心代码、有意义的错误，UT越详细越好