谈谈为什么写单元测试

单元测试是什么

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

项目存在问题

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

缺乏unit test意识 & 实践经验

框架对单元测试不友好

业务繁重

研发人手不足

当时工程面临问题：

代码耦合度较高

架构落后

各种bug

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

单元测试意义

减少bug

快速定位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，也怕别人不小心改了自己的代码（被害妄想症），新版本上线提心跳胆......花点时间写单元测试，有事没事跑一下测试，确保原逻辑没问题，至少能睡安稳一点。

TDD 测试驱动开发

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

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

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

总结

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

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

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

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

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

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

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

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

关于作者

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