重要的单元测试

👽System.out.println(“👋🏼嗨，大家好，我是代码不会敲的小符，目前工作于上海某电商服务公司…”);
📚System.out.println(“🎈如果文章中有错误的地方，恳请大家指正！共同进步，共同成长✊”);
🌟System.out.println(“💡如果文章对您有所帮助，希望您可以三连支持一下博主噢🔥”);
🌈System.out.println("🚀正在完成计划中：Java应届第一年规划 ");

文章背景

由于之前实习也没怎么写过单元测试，自己造两个数据测试没问题就直接扔给测试了，没有规范性。正好工作需要，这里系统补充一下单元测试的知识，单元测试和集成测试是不是常常混乱呢？实战代码模拟业务服务所编写的代码，更加容易理解！单元测试是我们开发需要做的，也是必备知识。

单元测试

由开发人员在代码发布前编写的不依赖于环境只针对程序模块进行正确性的校验的测试工作。
特征： 编写难度低、反馈速度秒级、码行覆盖60—80%、分支覆盖40—60%、全部模拟

1. 快速：花费很少的时间
2. 独立：单元测试是独立的，可以单独运行
3. 可重复：运行单元测试的结果应该是一致的，总是返回相同的结果
4. 自检查：测试应该能够在没有任何人工交互的情况下，自动检测测试是否通过
   

集成测试

由开发人员在代码发布前编写的依赖本地或日常开发环境针对功能级别进行正确性的校验的测试工作。
特征： 编写难度中、反馈速度分钟级、功能级别的测试、部分模拟

系统级别测试

由开发/测试编写的依赖预发或者生产环境的对核心保障链路进行正确性的校验的测试工作。
特征： 编写难度中高、反馈速度分钟级、系统级别的测试、真实环境

为什么要写单元测试

核心： 缩短反馈周期、降低缺陷修复成本

• 保证质量的前提下提升软件交付的速度

驱动设计：明确代码功能职责，帮助系统的设计灵活、松耦合
活文档：可执行且永远最新的说明文档
安全重构：后续开展重构时更安全可靠
易于调试：帮助开发者更快定位Bug
提升信心：能够在开发过程中快速得到反馈

如何做好单元测试

第一步：定义对象
测试对象、依赖对象、注入依赖对象
第二步： 模拟方法
模拟依赖对象、模拟依赖方法
第三步：调用方法
模拟依赖对象、调用测试方法、验证数据对象
第四步：验证方法阶段
验证依赖方法、验证数据对象、验证依赖对象
保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。

单元测试实战代码

GitHub - codenotknock/springboot-test: 单元测试 demo
单元测试实战为了更方便地进行单元测试，业务代码应避免以下情况：

• 构造方法中做的事情过多。
• 存在过多的全局变量和静态方法。
• 存在过多的外部依赖。
• 存在过多的条件语句。

说明：多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。

误解：

• 那是测试同学干的事情。
• 单元测试代码是多余的。汽车的整体功能与各单元部件的测试正常与否是强相关的。
• 单元测试代码不需要维护。一年半载后，那么单元测试几乎处于废弃状态。
• 单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。

最后

慢慢的来，别着急！学会有质量的走过每一步


我是代码不会敲的小符，希望认识更多有经验的大佬，也在努力摸索出自己的道路
欢迎交流，一起加油