Java基础学习总结(118)——单元测试的必要性和重要性

大部分程序员有两个特点:一不愿意写文档和注释,二不愿意写单测。单元测试是黑盒测试的基础,基本的准入测试,既能验证逻辑的准确性,又能给后续的接口重构提供基础。总之就是『单元测试很重要』,在敏捷迭代开发过程中,开发人员往往对单元测试不够重视,主要原因还是排期紧,比如我们团队初期对单测的要求是所有的 dao 层都要进行单测覆盖,到后来时间充裕才在 service 层进行单元测试的补充。controller 层的单元测试由于经常采用 mock 对象,很多人嫌繁琐就索性直接跟前端联调,不去管了。那为什么要写单元测试?单元测试能以更细的粒度,构造更多的业务场景,模拟更多的输入行为,在此过程中保证程序行为如程序员所想。单元测试可以驱动重构,通过重构进而优化代码本身,为什么这么说呢?因为单元测试对于被测试代码是有要求的,那什么是好的代码呢?援引一个我认识的架构师的观点,好的代码有以下特点:可读性。代码整洁有序;命名规范,见名知意(get/load, create/build), 在方法没有好到见名知意或者有特殊业务逻辑时,加必要注释。扩展性,易维护性。合理规划变和不变(核心业务逻辑不变);抽取模块、服务、方法;NO 复制粘贴效率。避免一个请求对远程服务/数据库重复请求可测性。避免大而全的方法,一个方法只做一件事(大方法抽取出多个可测小方法);相似的事情尽量合并成一个方法(比如 dao,sql 不要写死,尽量一个 sql 可以做多件事情)其中可测性是单元测试对代码的基本要求,所以当你发现代码不可测试了,是时候重构了,这也是一个代码重构时机的判断标准。
那么如何写好单元测试:单一职责,每个 case 测试一件事情,原子无歧义,失败无需 debug;case 按照业务场景拆分,注释保证覆盖全面,追加删除方便;测试的 case 间没有依赖;case 之间无冗余;case 干净。(数据库、磁盘、程序状态等)前后保持一致
最近负责一个复杂改动逻辑较多的迭代,对较多业务模块进行了重构,写了很多单元测试。所以顺便做个总结,单元测试是自己代码逻辑的检查员,是别人阅读你代码的入口,也是重构的保障

最近看 Eureka 的源码,看源码除了从任何一个函数作为入口着手外,有个很好的技巧就是从单元测试入手,本章最后来两张图来看下 Eureka 源码的单元测试,这种测试驱动的思想和做法值得我们学习。


图1可以清晰看到 eureka server 初始化过程:初始化配置、启动服务、创建 eureka server 加载配置,通过该入口进去可以看到 eureka 初始化的所有细节。


上图是服务的注册、发送心跳(renew 续约)以及失去心跳的入口,比直接找源码简单很多。

发布了810 篇原创文章 · 获赞 3117 · 访问量 330万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览

应支付9.90元
点击重新获取
扫码支付

支付成功即可阅读