身为测试人员如何推动开发做单元测试

今天有同学来问，怎么样能够让开发做单元测试？

结合我在公司推行单元测试的经历，来梳理下这个问题。

首先问这个同学的是，为什么他想推单元测试。对方给我的回答是说，好像开发很懒，就是版本提测的质量很差。修个bug，说是修好了让测试验证，结果居然还会引入新的bug。希望通过开发自测提高一下提测版本的质量。

这几乎是绝大部分测试团队推动开发自测的出发点。

有说一点要提醒的就是，如果下游测试团队只是对上游开发团队提要求，那往往这种要求是会被忽略，甚至干脆就引发反感，被认为是对其他部门内部事务的说三道四，指手划脚，尤其是你并不能就你所提的要求帮上什么忙或者带来什么好处，只是单纯的提要求。

当你和对方的意识或者态度共情的时候，讲越多的单元测试对质量保障的好处是没有任何益处的。

搞定对方领导-领导一句话，顶你干半年

如果要推进单元测试或者其它任何工程实践，那么一般来讲首选就是能先搞定研发负责人，可能是研发副总或者是某一个部门的负责人。某些同学可能就会讲我级别不够啊，反正无法直接和这个级别领导进行沟通，甚至要求对方做什么事情。所以这类事情我只能借助于我的向上沟通渠道，让测试领导去层层沟通。那这个过程就很漫长，而且往往最后可能这件事情就不了了之了

那即使是你有这样的机会去跟研发副总就单元测试这件事情进行沟通呢。管理层这个层面，一般来讲都会是支持，至少不会来反对，毕竟单元测试这是已经被证实的最佳实践。那要让对方做出这样的一个支持或者表态。所以这个时候的问题就是，你有没有试点成功的案例，可以让研发的领导来作为一个样板，这是第一个。第二个，其实更大的一个挑战是，你要考虑到当他跟他的下属去沟通这件事情的时候，那么下属往往会提出一堆的各种各样的问题和困难。最简单的来说，做单元测试的话，我的工作量要翻一倍，要不我们的迭代WIP数量减一半？这个事情要么领导你帮忙扛一下？因此，你对于开发团队会有什么反应应该有一个提前的预判，并且把这些问题以及说你能提供的这个解决方案跟开发的负责人讲清楚。让对方了解到这个事情，你是已经有了比较深入调查研究去才来跟他谈这个事情，而不是泛泛的说这个事儿。否则你泛泛说一下，他也只是表面应对一下。

那因为要跟高层进行沟通，所以很多同学可能到了这个环节可能就自己就先往后退缩了。毕竟向上沟通并不是很多人所擅长的。

寻找同盟者，培养氛围

那如果说我不能直接去搞定研发的负责人，然后让开发团队开始做单元测试。这事儿我不想放弃，或者说我还能做什么去推动这件事情？比如说你如果不能影响整个组织，那你能不能先影响一个团队，或者说至少能影响到一个开发吧。就是说我们从最小的范围开始。比如说你能不能找到一个愿意写单元测试的开发人员。找到一个已经在做单元测者做过单元测试的开发同学，测试的同学能不能跟他进行一个合作。你找到这样的一个人之后，把这个单元测试达人啊这种标签给他贴上去，进行一些宣传、鼓动，帮他把个人的声誉打出来。毕竟单元测试做得好的开发人员，他本身的那个绩效肯定也是不会差。这样，相当于说你在开发团队里面有了一个帮衬，后续再实施推广的事情就容易多了。

身先士卒，从0到1

那如果你这个人也找不到。那只能说一件事情往往是谁最痛，就由谁先出手解决。在团队层面，当其他人都没有能力或者意愿做的时候，你作为测试能不能先打个样。先拿到团队的代码库的提交权限，然后提交几个单元测试用例。在国内这样的文化氛围下，基本上一件事情，如果你只是嘴巴说说，你都自己不做呢，很难要求别人去做。所以，要求大家来做单元测试这件事情，就变成了我先带头做，完成从零到一，打破僵局的突破。仅仅靠先给大家打样的这些用例，很那真正能起到质量防护网的作用，但是它所起的作用是深远的，至少向周边的人表明了，推广实施单元测试这件事情，你是认真的。

很多事情，捅破了也就那么回事。最难的是从0到1，产生第一个用例。不过由于这事情超过了绝大部分测试人员的自我限定。他们天然地在潜意识里认为开发代码库于我无关，不能涉足，于是对于这种想法首先就会自我否定。