一文总结单元测试什么时候写&怎么写

发表于:2023-1-29 10:01

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:IntoTw    来源:博客园

  公司要求提升单元测试的质量,其中我作为方案和推动的主导,对开发过程中的单元测试,有了一些思考和总结。
  单元测试编写的目的
  单元测试编写的目的,是面向计算机特性的,基于函数的in-out,所以单元测试的好帮手就是断言,通过不断的构造输出并对结果进行断言,我们就可以针对一个对象以及它的函数,构建出充足的用例去包裹它,以期望它的任意行为满足我们的需要。
  最终的目的也是为了通过用例对单元测试的包裹,达到对任意对象的任意函数进行修改后,既满足新的功能,又对旧有功能没有影响。
  单元测试编写的原则
  基于单元测试编写的目的,在编写单元测试时,我们应当认为我们编写的单元测试所面向的过程是黑盒,我们应只对输入以及我们期望的输出负责,即只考虑起始输入以及最终态。
  具体来说:
  针对Dao的单元测试,我们只应该关心测试后数据库各个字段的值;
  针对Service的测试,我们只应该关心Service方法执行最终涉及到的数据库字段,缓存,消息队列中的值,以及Service方法的返回;
  针对Controller的测试,我们仅应该关心Controller针对HttpRequst的输入以及HttpResponse的输出,而不该关心其中具体调用到的那些Service如何执行。
  其中第3点或许令人疑惑,但是我们在编写单元测试时,我认为应该仅考虑执行的函数逻辑本身。对于其外部的依赖或者并不关心结果的方法,尽量mock掉。
  虽然目前的场景下Service层与Dao层基本耦合在一起无法拆分开来进行单元测试,但是Controller层绝不应该严重依赖Service来进行单元测试,否则单元测试最终会沦为接口测试
  同时,如果我们在测试某个模块时,不对其外部依赖做mock,那么就会导致我们的测试依然非常臃肿,并且最可怕的是,我们对结果的断言无法实现。
  比如当我们对Controller进行单元测试时,即便我们不mock它所依赖的Rpc(而是将他们启动着),但是我们如何对他所依赖的那些Rpc的执行正确与否进行断言呢?难道我们要在Controller层的单元测试执行完成后,在Controller层对数据库以及其他中间件的变化做查询以及断言吗?这显然是不现实的。
  单元测试面向的应该是一个从不调用其他函数(不包括第三方jar包)的函数,从其开始自底向上一个个编写,直到Http接口层。
  对于同一个单元测试来说,它的增加与修改应该与其对应测试功能的变化相同:
  当对应的功能增加了或扩展了,应在单元测试中对新增功能增加新的测试,对老的单元测试则应该不做修改,并保证新增功能也满足老的测试。
  当对应的功能修改了,并且不可能满足原有的测试,此时才应当去修改原有的测试,并应当加注释以说明。当需要修改单元测试时一定要谨慎,因为这意味着以前的经验已经不奏效了。
  依靠这些原则去编写单元测试,我们会发现,想要写出一个好的便于测试的类也是比较难的。想要写出便于测试的类以及方法,会反向要求了我们减少代码间的耦合,提高代码的可读性。
  单元测试编写的Timing
  单元测试的编写不应该是大家埋头一个月一起闭关编写(虽然大部分从未编写过单元测试的系统确实需要这样),而是一个不断渐进,防止犯过的错再犯的方式。
  当开发一个新功能时,我们应当对新功能针对需求编写单元测试,这是理所应当的。
  当对一个功能进行修改时,我们应该对该功能的单元测试进行修改,并完成该功能修改后的单元测试。
  当发现某功能出现了某些意料之外的输出(一般来说就是bug),我们在修改时,应当针对该种特殊情况编写对应的单元测试。
  经过以上3种情况的单元测试编写,我们的单元测试会覆盖的场景就会越来越多,我们的代码也会越来越健壮,久而久之,我们对于代码的修改可以纯粹依赖单元测试,而减少更多逻辑上复杂的思考。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号