谈谈为什么写单元测试

摘要：原文作者键盘男单元测试是什么单元测试是针对程序的最小单元来进行正确性检验的测试工作。因此，首要任务，就是对单元测试全面了解。作为一名经验丰富的程序员，写单元测试更多的是对自己的代码负责。

原文：http://www.jianshu.com/p/bc99678b1d6e
作者：键盘男kkmike999

单元测试 是针对 程序的最小单元 来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。一个单元可能是单个程序、类、对象、方法等。    ——维基百科

2016年之前，我司的Android项目都是用肉眼review + 真机测试做功能测试，对junit、robolectric、espresso望而生畏。其原因是：

缺乏unit test意识 & 实践经验

框架对单元测试不友好

业务繁重

研发人手不足

当时工程面临问题：

代码耦合度较高

架构落后

各种bug

由于缺乏单元测试认识、实践，导致对框架重构迷失目标。意识不足是很严重的问题，框架重构没有方向。因此，首要任务，就是对单元测试全面了解。

减少bug

快速定位bug

提高代码质量

减少调试时间
...

一个机器，由各种细小的零件组成，如果其中某件零件坏了，机器运行故障。必须保证每个零件都按设计图要求的规格，机器才能正常运行。

一个可单元测试的工程，会把业务、功能分割成规模更小、有独立的逻辑部件，称为单元。单元测试的目标，就是保证各个单元的逻辑正确性。单元测试保障工程各个“零件”按“规格”（需求）执行，从而保证整个“机器”（项目）运行正确，最大限度减少bug。

由于每个单元有独立的逻辑，做单元测试时需要隔离外部依赖，确保这些依赖不影响验证逻辑。因为要把各种依赖分离，单元测试会促进工程进行组件拆分，整理工程依赖关系，更大程度减少代码耦合。这样写出来的代码，更好维护，更好扩展，从而提高代码质量。

如果程序有bug，我们运行一次全部单元测试，找到不通过的测试，可以很快地定位对应的执行代码。修复代码后，运行对应的单元测试；如还不通过，继续修改，运行测试.....直到测试通过。

对于Android项目，要测试某个功能点，不用单元测试的话，必须运行在真机、模拟器上，慢慢debug找到问题点。运行程序到真机，快则半分钟，慢则几分钟。junit只需在本地运行即可，就几秒的事（robolectric需要十几秒）。有时，写那个功能模块的员工已离职，APP运行出错（逻辑错误，非crash or exception），你根本就不知道调试哪个类。如果离职的员工之前写了单元测试，运行一下立马就找到问题点了。单元测试大大减少调试时间，从而达到节约时间成本的效果。

重构，每个开发者都会经历，重构后把代码改坏了的情况并不少见。以往，写完一个框架，运行APP，没什么问题，完事。由于最初的框架并不是你写的，可谓牵一发动全身，你改1个方法导致整个框架运行失败....

如果你有单元测试，情况大不相同。写完一个类，把单元测试写了，确保这个类逻辑正确；写第二个类，单元测试.....写100个类，道理一样，每个类做到第一点“保证逻辑正确性”，100个类拼在一起肯定不出问题。你大可以放心一边重构，一边运行APP；而不是整体重构完，提心跳胆地run。

有些经验丰富的领导，或多或少都会要求团队写单元测试。对于有一定工作经验的队友，这要求挺合理；对于经验尚浅的、毕业生，恐怕要死要活了，连代码都写不好，还要写单元测试，are you kidding me？

培训新人单元测试用法，是一项艰巨的任务。新人代码风格未形成，也不知道单元测试多重要，强制单元测试会让他们感到困惑，没办法按自己思路写代码。

国外很多家喻户晓的开源项目，都有大量单元测试。例如，retrofit、okhttp、butterknife.... 国外大牛都写单元测试，我们也写吧！

很多读者都有这种想法，一开始满腔热血。当真要对自己项目单元测试时，便困难重重，很大原因是项目对单元测试不友好。最后只能对一些不痛不痒的工具类做单元测试，久而久之，当初美好愿望也不了了之。

都是有些许年经验的老鸟，还天天被测试同学追bug，好意思么？花多一点时间写单元测试，确保没低级bug，还能彰显大牛风范，何乐而不为？

笔者也是个不太相信自己代码的人，总觉得哪里会突然冒出莫名其妙的bug，也怕别人不小心改了自己的代码（被害妄想症），新版本上线提心跳胆......花点时间写单元测试，有事没事跑一下测试，确保原逻辑没问题，至少能睡安稳一点。

Test-Driven Development, 测试驱动开发， 是敏捷开发的一项核心实践和技术，也是一种设计方法论。TDD原理是开发功能代码之前，先编写测试用例代码，然后针对测试用例编写功能代码，使其能够通过。由于TDD对开发人员要求非常高，跟传统开发思维不一样，因此实施起来相当困难。

测试驱动开发有好处也有坏处。因为每个测试用例都是根据需求来的，或者说把一个大需求分解成若干小需求编写测试用例，所以测试用例写出来后，开发者写的执行代码，必须满足测试用例。如果测试不通过，则修改执行代码，直到测试用例通过。

好处，通过测试的执行代码，肯定满足需求，而且有助于接口编程，降低代码耦合，也极大降低bug出现几率（如果是极限编程，几乎是不可能有bug）。坏处，1.投入开发资源（时间和精力）；2.由于测试用例在未进行代码设计前写；很有可能限制开发者对代码整体设计；3.可能引起开发人员不满情绪，我觉得这点很严重，毕竟不是人人都喜欢单元测试，尽管单元测试会带给我们相当多的好处。

单元测试确实会带给你相当多的好处，但不是立刻体验出来。正如买重疾保险，交了很多保费，没病没痛，十几年甚至几十年都用不上，最好就是一辈子用不上理赔，身体健康最重要。单元测试也一样，写了可以买个放心，对代码的一种保障，有bug尽快测出来，没bug就最好，总不能说“写那么多单元测试，结果测不出bug，浪费时间”吧？

以下是个人对单元测试一些建议：

越重要的代码，越要写单元测试；

代码做不到单元测试，多思考如何改进，而不是放弃；

边写业务代码，边写单元测试，而不是完成整个新功能后再写；

多思考如何改进、简化测试代码。

作为一名经验丰富的程序员，写单元测试更多的是对自己的代码负责。有测试用例的代码，别人更容易看懂，以后别人接手你的代码时，也可能放心做改动。

多敲代码实践，多跟有单元测试经验的工程师交流，你会发现写单元测试获得的收益会更多。

关于作者

我是键盘男。
在广州生活，在创业公司上班，猥琐伪文艺青年。喜欢科学、历史，玩玩投资，偶尔独自旅行。希望成为独当一面的工程师。