让单元测试美如画

废话我承认，如果没有括号里的那几个字，这个标题看上去有那么点儿欠揍。

前言我们的网站越来越酷炫，我们的产品越来越丰富，我们的团队越来越壮大，我们的代码越来越复杂，我们的单测却越来越孱弱？有没有那么一个功能，看上去棒棒的，让你改又怕怕的？有没有那么一个class，看起来不知所云，想重构又爱莫能助？本文主要针对目前单元测试的现状作了一些思考，并尝试提出一些解决方案，希望能让我们的单元测试as pretty as a picture。

现状分析一句话概括，我们现在的单元测试处于基本停摆的状态。

- 流程上，目前仅有代码（行）覆盖率70%的要求，但实际上也并没有坚决地执行；- 数量上，虽然盲目地追求代码覆盖率毫无意义，但众多代码模块50%也未到的覆盖率已经说明了问题；- 质量上，由于缺乏维护，连最基本的100%的成功率都未能达到，质量从何谈起。

相信这种情况在集团内也并不罕见，特别是处于业务极速增长的我们，资源相对更加匮乏，必然会有一些取舍。

但这并非所有的原因，可能还有：* 对单元测试持怀疑态度；* 对谁来写单元测试有异议；* 资源紧张，无奈选择“轻流程、重效率”；* 执行单元测试的流程有问题；* ......一般来说，按照先后顺序，或者由小到大，测试分为单元测试、集成测试、系统测试。

而大家应该都认可“越早发现bug造成的损失越小”，那么单元测试作为最早进行的测试无疑有着最高的投入产出比。

在单测阶段扼杀bug，将风险控制到最小，将成本减少到最低。

我们有理由将单元测试做得更好：▪优质的代码不是测出来的，但单元测试的必要性是毋庸置疑的，它是代码落地后的第一道质量防线；▪单测代码也是代码，是我们产品的一部分，应当主要由开发来编写，我们是最熟悉被测代码的人；▪代码即产品，由开发和测试共同出品，测试为产品质量保驾护航，应该更多参与单元测试，提供专业的支持；▪没有质量保障的短期“效率”提升造成的可能是长期的风险、隐患，俗称“坑”；▪ Agile coding, Waterfall testing?拯救计划从流程上如果用一个字形容现在单测在项目中的角色，可能是一个“补”字。

功能代码开发完了，利用提测后的时间来补，往往还不一定能够补全，而如此一来单测的作用就可想而知了。

正常情况下，应当新增一个功能，就编写相应的单测，这是一个迭代的过程，项目的流程类似下图：如果细看单元测试这一子流程，开发和测试需要更紧密地合作：(注：真的是没找到不拿茶杯的...)这样做的好处不言而喻：# 提高开发测试的并行率，测试前置，风险更可控，提升代码质量，缩短项目周期；# 提升单测质量，“重单测、轻集成”，提升整体测试效率；# 互相促进，开发将更具有测试的理念，测试将更加熟悉代码。

从数量上说到数量，似乎自然而然，也似乎只能联想到测试覆盖率这个颇有争议的衡量标准。

难道我们要追求100%的覆盖率吗？If no, then how much?如果这是我们想问的问题，那说明我们已经走进了一个死胡同。

大牛有说过：任何追求百分百的事物都是值得怀疑的，这就好像写单元测试是为了讨那几个数字欢心，而完全不知道自己在做什么一样。

---- Martin Fowler那测试覆盖率的价值何在呢？那牛画了幅画：测试覆盖率应当引导我们发现哪些代码没有被测到，时不时地可以提醒我们：那些代码有bug吗？当然，有可能“有”，也可能“没有”再回到“数量上”来，既然覆盖率给不了我们答案，又该如何判断多少单元测试才算够呢？没有标准答案，也没有一定之规，需要根据情况，依靠经验来判断。

看看那牛有什么建议：如果做到了以下两点，我觉得你的单元测试足够了：- 你很少会遗漏bug，直到它到线上才发现- 你很少因为怕造成线上故障而犹豫该不该改一些代码那有没有可能too much呢？是的，单元测试会不会太多了？嗯，你猜对了，还是那头牛：如果你可以去掉一些单测，那说明你的单测太多了。

但这很难判断。

如果你的单测明显地拖慢了你的节奏，这就是单测太多的一个信号。

例如一个简单的代码修改却需要在单测上做很多的修改，这意味着你的单测很可能出了问题。

也许并不是你测试了太多东西，而是你的单测中有重复的用例。

另外一个值得参考的做法是，根据风险大小将单元测试分类，并按风险高低决定投入多少（单测用例的多少）1. 高风险可能造成重大故障（例如：影响下单主链路、造成资损）、影响大面积用户使用或者已经发现过很多bug或者故障的功能；2. 低风险非核心功能且不太可能出bug，即使有bug也不影响使用；3. 中等风险介于前两者之间，单一的bug不会影响某一主流程的正常进行理论上，项目发布前，会看到高风险的单测用例最多或是测试覆盖率最高，中等风险的次之。

显然，这里没有一个标准的公式或者模型来自动分类，参考历史数据（故障、bug）和经验积累将作为主要手段，测试（后）、发布（后）的review 将作为有效的补充。

从质量上Green Bar成功率100%是一切的基础，运行失败的单元测试只能说明两种情况：1.被测代码有问题，有bug未被修复；2.单测代码有问题，已经out of date。

单测设计单测的目的不是green bar，也不是100%的覆盖率，而是测试。

单测用例的设计决定了单测的质量，是针对条件判定、边界值、robustness或是error guessing，这需要测试同学的专业协助。

规范、约定其实我们已经有这样的一套规范。

这样再补充或强调几点：一、单元单元测试是粒度最小的测试，它所关心的应该是被测单元本身，而不是被测单元所依赖的那些代码。

我们应该隔离这些依赖对被测单元行为的影响，专注于单元。

二、Mock通过mock达到隔离的效果，service的单测mock掉dao，business的单测m ock掉service。

并非mock所有dependencies，而是对已有单测覆盖的和测试环境难以保证稳定性的dependency进行mock。

三、Assert通过assert来自动验证测试是否达到预期，避免system.out.print()人肉检查，避免Assertion Free Testing。

最后还是得说，坚持地执行往往比规范本身更重要。

Best Practice关于mock工具目前比较popular的主要是mockito(powermock)和jmockit，这里推荐jmockit，不解释。

Talk is cheap. Show me the code.---- Linus Torvalds下面演示两种可能会比较常用的用法：1.Injectable mocked instance// tested codepublic class OrderServiceImpl implements OrderService { ProductRemoteServiceproductRemoteService;publicOrder createOrder(String productName, Integer quantity) { Double productUnitPrice = productRemoteService.getProdu ctUnitPrice(productName);Orderorder = new Order();order.setProductName(productName);order.setOrderAmount(productUnitPrice * quantity);// DB operation: persist a new orderreturnorder;}}importmockit.Expectations;importmockit.Injectable;importmockit.Tested;importmockit.Verifications;import mockit.integration.junit4.JMockit;importorg.junit.Test;importorg.junit.runner.RunWith;// unit test code@RunWith(JMockit.class)public class OrderServiceImplTest {@TestedOrderServiceImplorderServiceImpl;@Injectable ProductRemoteServiceproductRemoteService;@Testpublicvoid testCreateOrder() {new Expectations() {{productRemoteService.getProductUnitPrice("mp3"); result = 5d;}};orderServiceImpl.createOrder("mp3", 5);new Verifications() {{productRemoteService.getProductUnitPrice(anyString); times = 1;}};Double d = 5d * 5d;Assert.assertEquals(order.getOrderAmount(), d);}}2.Mocking static method// tested codepublic class OrderServiceImpl implements OrderService { publicOrder createOrder(String productName, Integer quantity) { ProductRemoteServiceproductRemoteService = RemoteServiceFactory. getProductRemoteService();Double productUnitPrice = productRemoteService.getProdu ctUnitPrice(productName);Orderorder = new Order();order.setProductName(productName);order.setOrderAmount(productUnitPrice * quantity);// DB operation: persist a new orderreturnorder;}}importmockit.Expectations;importmockit.Tested;import mockit.integration.junit4.JMockit;importorg.junit.Assert;importorg.junit.Test;importorg.junit.runner.RunWith;// unit test code@RunWith(JMockit.class)public class OrderServiceImplTest {@TestedOrderServiceImplorderServiceImpl;@Testpublicvoid testCreateOrder() {new Expectations(RemoteServiceFactory.class) {{RemoteServiceFactory.getProductRemoteService();result = new ProductRemoteService() {@Overridepublic Double getProductUnitPrice(String productName) { return5d;}};}};Order order = orderServiceImpl.createOrder("mp3", 5); Double d = 5d * 5d;Assert.assertEquals(order.getOrderAmount(), d);}}关于Assert目前我们比较常用的是Junit的assertEqual、assertNotNull、assertTrue等等，这里要推荐更加美如画的Hamcrest(已经集成到junit中)。