谈谈为何写单元测试

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

单元测试是什么

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

---

项目存在问题

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，浪费时间”吧？

如下是我的对单元测试一些建议：

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

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

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

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

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

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

---

关于做者

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