当我们谈论Unit Test时我们在谈论什么？(2)

具有算法和业务逻辑的代码。这部分代码我们应该重点关注，最为典型的就是一些公共类，基础Service层等。尽量为它们写上详尽的UT，造福后人。
最后一类是非常复杂的代码。各种复杂逻辑交织在一起，牵一发而动全身，我们本能地可以感觉到代码中的“坏味道”。对于这类代码，首先应该考虑做代码的清理工作（由粗到细重构），过程中不断为小单元注入Unit Test，最后形成一张严密的代码保护网，将原来的代码切碎为可维护的代码。
在实际开发中对第四点可能有些争议。对于公司或者团队来讲，一个产品的代码不可能始终是一个人负责，但往往新的同事接手老代码时不知道从哪下手。我的第一份工作，当我作为一个毕业生，第一次接手一个完整的项目代码，一上来就是一个好几千行的函数，其中包含的各种请求的发送，变量的随意命名与重复使用，还有各种复制粘贴的痕迹。你能想象对于一个新人来讲这是多么的绝望吗。
作为一个实际写代码的Coder，老代码能不碰就不碰---我举双手赞成，既没有UT，逻辑又混在一起，天知道改完以后会出什么Bug。
但是对于团队来讲，如果明确知道这个模块无法测试、无法被很好的修改，那么是时候把这部分代码提上重构的日程了。
其实我认为代码的组织与规范（包括UT）是开发流程中非常重要的一部分，在一开始我们就应该定期进行CodeReview，避免写出无法维护的代码。一个团队可能会负责多个项目，这些项目应该是属于团队中的每一个人，而不是谁负责，其他人就可以不管。我们应该把项目的Dev和Ops视为自己的责任。有太多的项目由于走形式的CodeReview、没有UT、没有文档，导致最后无法维护，这是我们都不想看到的。
UT是不可能写的，这辈子都不可能写的，老代码就只能让它勉强运行下去这样子~
四. 怎么做Unit Test
至于如何做UT，网上一搜一大把的教程，这里就不赘述了，只是列几条个人总结的值得注意的点：
多组数据（考虑周全）->正常业务测试，边界条件测试
不要误用Mock工具，理清需要被Mock的对象
整体覆盖率没有意义，但是关键业务代码覆盖率很重要
运维时：每一个BugReport都应有一个对应的UT
UT并不是越多越好，而是对于核心代码、有意义的错误，UT越详细越好

原文转自：https://www.jianshu.com/p/8e11c8fa63af