ASK MO第41-2期 | 有没有好的方法衡量单元测试的投入产出？

测试的工作不是把代码写出来而已，代码的质量就是软件产品的生命。又因为代码的修复成本越在后期会越高，所以最低的修复成本就是单元测试之后进行。不写单元测试，不做单元测试，最大的原因就是“懒”。我不知道开发同事为什么单元测试时间会这么长，如果每天都触发持续集成，然后再做手工单元测试的话，其实只需要5分钟就可以了。除非小伙把单元测试做成了自动化，还要去维护自动化测试代码。

如果是这样，就更值得表扬了，因为如果这个测试要跑100遍的话，自动化完胜手工。自动化单元测试的意义在于知道你改了其他代码会对这段代码有何影响。单元测试的投入产出，得和BUG的严重级别，在后期测试出来的修复成本挂钩，比如我们做一次单元测试之后，修复一段代码需要多久，来和转测试以后，测试给你提BUG的平均时长，来计算这个修复成本，拉上数据一看，要不要搞单元测试一目了然。

最后，我觉得不管业务到底有多忙，我们的评估时间的时候，单元测试时间得放进去。写代码有时候就像做菜，你做菜做得再快，结果菜端上去一尝，不是盐放多了就是把酱油放成了醋，你觉得大家还会对你有一个高的评价吗？