单元测试：实践者的总结和反思

      我是单元测试的实践者和拥护者，我将单元测试引入项目并持续推进它，督促代码的提交者编写相关测试代码。我也确实从单元测试中得到好处：更高的代码自信心；更好的软件质量；更快的开发速度——正如大多敏捷方法论者许诺的。
      但我和大部分敏捷方法论者不同，我并不是单元测试的狂热者。单元测试不是有利无害的万能药，更不可能解决软件开发中遇到的一切问题。也许他们的本意是好的。但是过分吹捧反而不利于单元测试真正推广，只会带来误解、失望和放弃。我见过不少项目组经历了这个令人沮丧的过程。最后leader不再相信方法论者的承诺，一切又回到了原点。
      所以，我现在想总结我在单元测试实践上的经验，以免后来者走弯路。
      和方法论者的结论不同，我认为单元测试不是万能药，很多情况下其实是不宜使用单元测试的——它们只会带来额外的工作量，所收获的却非常少，而且将来代码重构又要修改大量的测试代码。c++没有比较好的测试覆盖率统计工具，但是即使有我也不care。因为追求测试覆盖率就跟单纯追求gdp一样，只是面子上好看，与软件质量无关。以下情况不宜使用单元测试：
      1）界面层的代码不要单元测试。因为它们的问题很容易发现——只要一个测试小妹妹就能发现大部分defect。而测试代码却要很多，需要程序员工作好久。而且这种测试代码非常没有营养，程序员非常厌烦。最后测试效果后者还往往比不上前者。还有一点很重要：界面的变动往往是很大的，可能一次变动就废弃几百行测试代码，太折腾了。
      不过：如果你在界面层直接写算法和复杂逻辑，我也只能服了你了。重构吧。把算法剥离界面层。
      2）太简单的代码不要单元测试。void setValue(int value){this->value_ = value;}。很多单元测试教程测试类似这种代码，这种代码没有测试的必要。写了只是浪费时间。如果写这种代码经常出错的程序员，应该考虑的是炒掉而不是引入单元测试——他写单元测试一样也会出错的，说不定还是啥都没测出来。
      3）单元测试过于复杂的代码不要测试。有人说单元测试的手段可以用来做集成测试。这在一些情况下是对的——对于那些输入输出相对简单，但处理过程很复杂的应用来说是适用的。但大多数集成测试输入输出一般都比较复杂。以至于构造一个测试用例需要花费大量时间和很多行代码。的确，这样可以为重构建立一道防火线，但这边存在一个悖论：如果系统很稳定，单元集成测试的意义不会很大；如果系统还在开发中，则输入输出很可能发生变化，测试代码也要频繁修改。我个人觉得不应该在自动化集成测试上花费过多的时间。如果这件事情很容易做，那很好很幸福，就做吧。如果做起来很艰难，要懂得知难而退，把精力花费在更有意义的事情上。
      4）还在调研中的代码不要测试。这点是和TD极端主义者的信仰矛盾的。但如果一个算法正在技术调研，你对它经过几步用啥数据结构都不确定，怎么去写测试代码？如果尽写些很宽松的判断，其实也没啥意义。
      这也不要，那也不要，可能有人想知道我们项目最后代码的测试覆盖率大概多少？这个我没精确统计过，大概是10%左右吧，但我们确实从中得利不少。我觉得要想用好单元测试，先得摆脱覆盖率迷信。测试需要测试的，不测无需测试的，做一个实用主义者。