消灭低级错误
基本的单元测试，可以在系统测试之前，把大部分比较低级的错误都消灭掉，减少系统测试过程中的问题，这样也就减少了系统测试中定位和解决问题的时间成本了。
找出潜在的bug
某些类型的bug，靠系统测试是很难找到的。例如一些代码分支，平时99%的场景基本上都走不到，但一旦走到了，如果没有提前测试好，那么可能就是一个灾难。
上库前的保证
加了新代码，上库前跑一把单元测试，都通过，说明代码可能没有影响到之前的逻辑，这样上库也比较放心。如果之前的单元测试跑不过，那么很有可能新的代码有潜在的问题，赶紧修复去吧。
重构代码的机会
写单元测试的过程中，你可能会顺手把一些code重构了，为什么？举例，一些长得非常像的代码，如果每次都要写一堆测试代码去测同样的code，你会不会抓狂？不测吧，覆盖率又上不去，于是我就会想方设法把待测试的code改得尽量的精简，重复代码减少，这样覆盖率上去了，测试也好测了，代码也简洁了。如果没有单元测试和覆盖率的要求的话，坦白说可能一来自己不会发现这些重复的code，另一方面即使发现了，可能也没有太大的动力去改进。
另外，由于单元测试中，你需要尝试去覆盖一些异常分支，这是系统测试常常走不到的地方，于是就会引起你的一些思考，例如这个异常分支是否真的需要？是否真的会发生？对于一些实际上绝对不会出错的函数，那么我觉得可能异常分支是没必要存在的。
重新review代码的机会
写UT的过程中，我总是会好好看哪些代码执行到了，哪些代码没有执行到，这其实也是一个review自己代码的机会，有些时候，并不是UT本身帮我找到bug，而是回头review自己代码的时候发现的。
网友评论