关于如何提升团队的代码质量，我曾经做过很多尝试。由于团队成员都有繁忙的开发工作，公司也不是学校，不可能投入太多去面面俱到地教层层选拔招聘进来的程序员这些基础知识，所以，做法一般是以点带面，比如引入sonar代码检查推动大家去掌握一些以前未曾注意到的编码细节，比如通过针对性地培训降低代码的认知复杂度让大家掌握常用的重构技巧和设计方法。这些都能取得一定的效果，这次我想从自动化单元测试入手，更进一步……
什么是单元测试
教我的儿子Allen学习Scratch/Python和乐高是我周末最主要的一项“娱乐活动”，从孩子的视角去看待和学习编程语言和工程技术会给人很多意想不到的启发。正如上面的图片所示，有一次，Allen在用乐高积木做一辆小车，当他把轮子组装好的时候，他会用手指拨弄一下，看轮子能不能转动。这时车子还远远没有成形……他竟然在做单元测试！！！
Allen的这一个举动让我感到惊喜，我甚至开始幻想他未来一定会成为一个出色的工程师！他明白尽可能早，尽可能小地去做单测，这已经超过我工作中见过的80%的软件工程师了，在我看来，我所见过的大部分开发者做单测的时机都不够早，单元的粒度也不够小。
后来我看了一部名为《狼伴归途》的电影，这部电影让我意识到我陷入了“自己家的孩子，别人家的老婆，怎么看都觉得好”的思维误区里——Allen明白的“尽可能早，尽可能小地做单测”的这个道理，我们的祖先在石器时代就已经明白了。
他们在制作长矛的时候，先会用石头打磨矛头，每磨一段时间，他们就会将即将成形的矛头在皮毛上划一下，验证矛头是否足够锋利，只有矛头合格了，才会给它装上一个长柄。
想想我们工作中整日忙碌，把自己还不太清楚是否足够锋利到能刺破动物皮毛的矛头和满是低级缺陷的粗糙的长柄迅速组装起来匆匆提测并交付给猎人的程序员们，被大家戏称为程序“猿”其实是实至名归——大部分人的技艺还处在非常原始的状态，还没有进入石器时代。
“尽可能早，尽可能小地做单测”是我们这支人类赖以繁衍下来的最基本技能，它已经固化到Allen的基因里形成了固有行为模式。
为什么要做单元测试
孩子和原始人进行单元测试是基于一种本能或传统，他们不知道这背后的深层次原理。当我们提到测试的时候，不得不提到的是这个测试金字塔。
测试金字塔有多种的分层方式，上面这幅图引自《TheCleanCoder》，不论哪种分层方式，其背后体现的经济学原理是一致的。
首先，越是在底层的测试类型，其测试的成本越低，反馈越及时。在单元测试阶段能发现的一个缺陷，假设修复它的成本是10块钱，那如果它没有在这个阶段被发现，而是推迟到了组件测试阶段，那修复它的成本是元，以此类推，每晚一个阶段发现，其修复成本都会增加一个数量级——想一想那高昂的沟通和回归成本吧。如果在线上才发现这些缺陷，那成本和损失就更难以估量。
基于上面的原理，专业的开发团队应该选择一个合理的测试策略。
首先是测试覆盖率的要求不一样。单元测试的覆盖率终极目标可以追求%，但系统测试能做到10%就已经很昂贵了。
其次，是每种测试类型的