迄今为止，就在对日外包当中接触过完整实行的单元测试，不过那是纯人工的单元测试，不是像 Junit 这样的靠测试代码的单元测试。体验上，跟你们开发的反馈差不多，极度消耗时间，且表面上看没收益（对于项目来说是另一码事）。

不管你是调通后再做测试（人工单元测试只能这样），还是编码完成就做测试，单元测试时间跟编码时间的配比，都要至少大于 1:1 。如果不给单元测试分配时间成本，或者在这上面压缩成本，那就不如不做。这个时间成本不一定会提高总成本，因为如果做好单元测试，那么集成测试跟系统测试的成本必然会减小。我参与那个对日外包开发，测试时间基本全部分配到了单元测试上，后面的集成、系统、交付测试的时间非常短。

收益这方面有点复杂，开发过程和考核指标，以及个人的职业发展规划，都会影响对收益的观感。如果你们不管多复杂的开发过程和考核指标，最终都是以项目是否收到尾款作为实际的考核依据，那么单元测试就真得是零收益。如果开发过程上不把编码人跟代码绑定起来，最常见的就是项目结束了就把人派去其他项目，那么单元测试不但是零收益，还是为他人栽树的负收益。如果个人职业规划没有向项目管理、需求或业务方向上发展的话，那么不止单元测试，所有测试对于编码人员来说都是零收益。

最后一方面，单元测试是谁推的也很重要。作为代码质量的一部分，单元测试应当是开发人员自行作为推动动力的。QA 推动也能推起来，不过会遇到阻力的。而假如是开发人员和 QA 之外的人推动，那基本就是全阻力。