28 | 理论二：为了保证重构不出错，有哪些非常能落地的技术手段？

单元测试很重要，但是为什么大多人都会放弃？我个人觉得最主要的原因并不是代码量大，难以编写等，而是跑单元测试的次数少。很多单元测试都是为了写而写，写完一次可能都不去运行或者只偶尔运行一两次。如果是每次改完代码，都跑一遍单元测试，单元测试的效果会越来越显现。如果只是为了运行一两次或者干脆为了写而写，很容易就会放弃继续写单元测试。

之前公司要求新研的代码要达到百分之85的覆盖率，导致纯粹为了覆盖率堆砌了一堆单元用例。有没有单元测试写的比较好的开源框架推荐下？

说起来真的是难受。整个项目中就我一个人写单元测试。每次做的功能都有单元测试覆盖。而且项目中junit包都是我导入的。更加奇葩的是我的功能单元测试领导还不让我提交。说是你的测试代码为什么要提交，我瞬间无语了。

打卡~ 这里问下王争老师，如果到了具体的业务代码，该怎么写单元测试呢，单元测试正确标准是什么呢，以sql查询到的结果吗？

程序员这一行业本该是智力密集型的，但现在很多公司把它搞成劳动密集型的，包括一些大厂，在开发过程中，既没有单元测试，也没有 Code Review 流程。即便有，做的也是差强人意。 ---------------------------------------------------------------------------------------- 差强人意：指尚能使人满意。根据文章上文，明显是不能使人满意的意思。处理为语病。

以前在开发中，没有写单元测试的意识。开发完功能后，直接去测试一个完整的流程。即前端发请求，服务端处理，看数据库数据。如果功能正确就过。这是从一个功能宏观去考虑测试。而单元测试是更细粒度的测试，它在保证各个“单元”都测试通过的情况下整个功能模块就测试通过了。这样的方式对于我们自己来说对代码可控粒度更细。更能比较清楚的理解某个“单元”在整个功能模块调用链路上的位置，承担什么职责，以及有什么行为。而不是一开始就站在模块宏观角度来思考。通过一个个单元测试的编写，将整个功能模块串联起来，最终达到整个功能模块的全局认知。 这也体现了任务分解的思想。通过单元测试，可以从另外一方面实现对已编写的代码的CodeReview，重新梳理流程。也为以后有重构需求打下基础。 目前参与的项目中有单元测试，但是不够完备。可能由于某些原因（开发人员意识问题，团队对单元测试的执行落地程度不够等）。在写单元测试的过程中，遇到单元测试依赖数据库查询问题，因为存在多套环境，如开发环境，仿真环境，线上环境。对于依赖数据查询的单元测试，只能自己造假数据来解决。不知道还有什么好的解决办法。

独立开发者，项目代码量 10W 行以内，在可以预见的未来不会超过 20W 行 以前试过 git 各种最佳实践，最后发现一个分支基本就够用了 所以还是忍不住想问问老师，如果项目真没那么大，是否需要单元测试？

参与的项目都有单元测试，不过有些不够完备，缺少了一些corner case的覆盖，感觉后面要注意加上。遇到的一个问题是对于repository层（数据访问层）的测试，用了一个取巧的办法解决的，因为要依赖数据库，可是又没找到对应数据库的mock方式，所以使用了docker镜像的方式来做的，感觉也不错，避免了构造数据的麻烦。不知道还有没有更好的办法？

争哥。马上过年了，过年期间不知道能否多发表几篇在过年期间学习？

问一下单元测试中的依赖问题只能用mock来模拟吗？这样不会导致对下层方法依赖太强，而且用mock模拟感觉代码量也很多，心里感觉也不一定对。如果加入依赖（先倒入测试数据），那不就变成集成测试了吗？