我不写单元测试，被批了

不写单元测试被批评是合理的，因为单元测试在软件开发中具有重要作用，以下从单元测试的定义、重要性、编写方法及不爱写的原因等方面进行详细分析：

单元测试的定义：单元测试是对某个类中的代码进行测试，查看是否正常。它是开发人员针对软件中的最小可测试单元（通常是函数、方法或类）进行的验证测试。
单元测试的重要性
便于调试：当想测试部分代码逻辑是否正常时，直接构造数据进行调试可能比较繁琐且不统一。单元测试可以将这些构造数据的代码统一管理，方便后续的调试和维护。
回归测试：在一个系统中修改了很多代码后，不确定改动是否影响核心逻辑时，单元测试可以在编译时自动跑一遍逻辑做回归测试。无论是重构还是正式提测前，都能提高开发人员写代码的信心，确保代码的稳定性和可靠性。
提高代码质量：单元测试促使开发人员在编码时就注重代码设计，避免将代码写成难以维护和扩展的“一坨屎”。通过编写单元测试，开发人员需要思考如何使代码更易于测试，从而推动代码结构的优化和设计模式的应用。
提升KPI：如果在一个季度内没有明显的开发成果，但系统没有发生过故障，单元测试可以作为一项重要的工作成果在KPI上体现。它展示了开发人员对代码质量的重视和努力，有助于提升个人绩效评估。
单元测试的编写方法
环境搭建：在SpringBoot环境下使用Mockito编写单元测试，只需引入spring-boot-starter-test依赖，它默认内置了Mockito相关的依赖。示例代码如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId></dependency>- 测试类位置：单元测试类应写在对应的`test`目录下。可以使用插件（如`squaretest`插件）根据主类自动生成对应的测试类，无需手动建包和建测试类。

- 学习框架：了解Mockito的API和概念，可以通过阅读相关教程（如

https://www.letianbiji.com/java-mockito/mockito-mock.html

）来学习。- 动手实践：亲自动手写一个单元测试，了解其编写过程和感受体验。在实际编写过程中，加深对单元测试的理解和掌握。

- Mock对象的使用：在测试时，对象可能是Spring下的，不能直接new，或者new出来的对象成本很大（还得解决依赖等问题）。这时就需要使用Mock对象来模拟创建对象。- Mock和Spy的区别：Mock和Spy都是模拟创建出一个对象，区别在于Spy模拟创建出的对象会真实调用方法，而Mock模拟创建出的对象不会真实调用方法。- Stub的概念：当Mock模拟创建出来的对象不会调用真实方法，但又想验证其流程时，就需要使用Stub。例如，在写service层的单元测试时，认为dao层的代码是正常的，但service需要dao的对象访问数据库。这时可以Mock出dao的模拟对象，并假定调用dao层的某方法时它的返回值是什么，这个过程就是Stub。

集成测试的编写方法：很多时候可能需要依赖Spring环境跨模块去调试功能是否正常，这时可以使用@SpringTest来修饰测试类，指明需要Spring环境。既然有了Spring环境，@Autowire之类的注解都可以使用。在web模块下启动时，会真的启动应用相关的环境，然后专门跑这个测试方法。
不爱写单元测试的原因
测试与业务代码的关联性：很多开发人员是写完业务代码后再回过头来写单元测试，且是自己Mock出来模拟对象再Stub。整个过程中都认为自己的业务代码是正确的，因此看到单元测试结果为绿色（通过）并不意外。这种情况下，单元测试可能无法真正发现潜在的问题。
时间成本：写单元测试的代码也是代码，需要花费时间。在项目进度紧张的情况下，开发人员可能会优先保证业务代码的完成，而忽略单元测试的编写。
团队氛围：部分开发人员询问了腾讯、滴滴、阿里、字节等公司的朋友，发现他们也不爱写单测，很多时候写单测只是为了通过编译、满足业务覆盖率的要求，能绕开就绕开了。这种团队氛围可能会影响个人对单元测试的积极性和重视程度。

您可能感兴趣问答

Collapsible

热门标签

热点问答