如何写单测

痛点

改完代码上线后，对于改动的地方，不自测吧，可能有bug，整体流程自测吧，成本又挺高，有些改动较为难覆盖。那咋整？

很多同学这时首先会想到单测！假如我们有个理想的单测，改完代码后跑一下，一切问题都解决了。

然而又引入一个新问题，如何写单测？怎么维护单测？好像没啥思路，最后的结果通常都是自测，或者不自测，而不是写单测。。

什么是单测

什么是单测？ 这个概念很重要，理解这个概念才能设计好单测。从准确的角度讲，单测其实是一种细粒度的测试，能测到函数维度，在单测之上，还有不同粒度的集成测试。这里要划重点，不同粒度。大家需要的其实是一种测试手段，相对比较方便的，而不一定是单测，但为了讲述清楚，符合大家日常的表达，下面都作为单测来说。

如何写单测

这是大家常常讨论的一个问题，据我待过的几家公司，没有哪个公司能做的非常好。单测其实是一件很难的事情，非常考验大家的能力。

首先代码要有良好的设计，所谓的可单测性。比如你在一个函数里，同时包含了一段复杂的计算逻辑，以及IO的逻辑，那么这个基本就不好测试。根据实际经验，要把计算逻辑，和IO逻辑剥离开。计算逻辑走单测的模式是可行的，至于IO逻辑，建议根据实际情况，有些mock的工具，比如java里的一些mockito，有些本地IO的方式，比如mysql的测试方法，或者不写其实问题不大。。

其次要注意粒度。常常有很多单测写的特别细，这个和代码的可维护性是矛盾的。一旦代码进行局部重构，都极大增加了成本。应该设计合适粒度的测试用例，保证这个模块改完后，跑下相关测试用例就可以了。至于到底几个单测，这个和代码的复杂度，以及开发人员的水平有关。

最后注意覆盖率，从准确性来讲，应该是每个函数都有单测覆盖，当然不意味着每个函数都是一个单测。没有人能保证自己修改代码不出bug，所以还是要保证至少主流程都是覆盖的。

结论

所以，最后终结下，写单测不要误入歧途。不要太多，也不要太少，选择合适的粒度，计算和IO相分离。