我讨厌单元测试：滕振宇谈如何进行单元测试

说起单元测试的好处相信大家都能列举出不少，可是很多时候，开发人员面对自己产品的代码，想写单元测试却无从下手，久而久之，便会有人大喊：“我讨厌单元测试。”资深敏捷咨询师腾振宇（Daniel Teng）在 GTUG-TopGeek 开发工程管理沙龙就以此为题，结合最近的一个项目，和大家分享了他对单元测试的一些看法。

Daniel 先介绍了下最近的一个项目，虽然不是遗留系统，但代码已经惨不忍睹，而且缺乏必要的测试保障，要修改代码可谓举步维艰。例如，一段代码和结对伙伴读了半小时没读懂，找来原作者看着注释又想了 10 分钟，终于才搞明白这段代码是做什么的。根据二八原则，先找到那 20% 的点，修改它带来 80% 的价值。最直接的做法就是寻找代码库里最常被修改的文件，一般的文件只有几次修改，有的文件则被修改了几十次，每个人都在往复杂的代码里加入新的东西，但没有人往里面加测试，于是第一步就是为它增加测试。

很多开发者会说老项目就算了，如果新启动一个项目，我就会写单元测试了，Daniel 认为这是一个“美好的梦想”，很多原因会打破它：

• 代码已经很烂了，又没办法下手了
• UI 不好测
• 认为这是 QA 的工作
• 写的单元测试找不到 Bug
• 代码的外部依赖太多
• 代码稍作修改，测试也要一并修改，太麻烦了

究其根本原因，是开发者根本不会写单元测试！满足什么标准的测试才是单元测试呢？根据《修改代码的艺术》，需要访问数据库的测试不是单元测试，需要访问网络的测试不是单元测试，需要访问文件系统的测试不是单元测试……

为了更方便地进行单元测试，业务代码应避免以下情况：

• 存在太多条件逻辑
• 构造函数中做的事情太多
• 存在太多全局状态
• 混杂了太多无关的逻辑
• 存在太多静态方法
• 存在过多外部依赖

例如，在代码中存在硬编码，或者是直接创建了一个数据库连接，这种做法都是比较危险的，因为在测试时没有办法“偷梁换柱”。

想要写好单元测试，学会重构是很重要的，重构的过程类似于清理厨房，虽然和做饭没太大关系，但可以让您下次做饭更方便，心情更好。可以重构的地方包括，在待测试类与其依赖之间增加一层 Test Fixture；将创建逻辑与业务逻辑分开等等。重构可以采取以下策略：

• 编写测试代码建立基本的防护网。在单元测试和功能测试之间要有取舍，如果单元测试实施成本很高，可以先加功能测试。
• 通过增加中间层来打破依赖，不是为了去掉依赖，而是为了后续的修改以及测试的便利。
• 将第一步中编写的功能测试换成单元测试。

最后，Daniel 还为大家提了一些建议：

• 项目里的破窗要修好，别容忍别人加新的破窗，用测试将破窗保护起来。
• 当你离开一个地方的时候，要让它比你来的时候更整洁干净。（童子军军规）
• 不停地重构你的代码，每次走一小步。

随后有人提问，如何评估一个单元测试的质量，用代码行覆盖率是否可行。Daniel 认为没必要去追求代码行覆盖率，真正要覆盖的是逻辑，而不是代码行。通过结对编程可以减少低质量的单元测试，人都喜欢改变，但没人喜欢被改变，不要强求结对编程，让他看到好处，尝到甜头，吸引他来做结对编程，没有人喜欢落后，比如 50% 的人在做结对了，剩下的人自然会想尝试。

当被问及单元测试是否是必须的时候，Daniel 回答这并不是必要的，而是需要进行综合的衡量，比如你的竞争对手一周前推出了一个产品，你需要在一周内完成产品研发并上线，这时可以选择写或者不写单元测试，对于没有写过单元测试的人，一开始是需要上手的成本的。

如果您也对单元测试的话题感兴趣，不妨关注腾振宇的博客和微博，也可以观看会议视频。