ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

写单元测试,我不认为是件容易的事

2022-01-08 10:02:09  阅读:125  来源: 互联网

标签:逻辑 依赖 IO 外部 单元测试 认为 测试 容易


这是一个40多岁还在编码的老程序员对单元测试的理解和实践。里面没有废话,希望每句话能说到你心坎里。

原则:只测自己

自己的含义:方法边界内的主体逻辑。一切下游方法、框架依赖、外部IO等都不是自己。如spring、 外部数据库都视为外部逻辑。

这一原则的动机

便于定位

每个方法有自己独立的单元测试,这有利于IDE在单元测试与逻辑代码间跳跃,便于定位,并降低代码结构调整的影响范围。

不重复,降低复杂度

因每个方法有自己的单元测试,所以当前测试不要涵盖下游方法的功能测试。以避免逻辑改动造成不必要的影响范围扩大。

实践与建议

要想单元测试更易于维护,良好的设计是前提

分层开发

开发也是可以分层的,先进行框架开发后进行具体开发。如先定义好所有的接口和要传递的数据,并组织好控制层,然后测试和具体开发便可同时展开。这样便可提前发现结构性问题,提前对设计进行验证,减少后期结构性调整对单元测试的影响。

单一职责

尽量应用单一职责设计模式,使逻辑模块化,并使用老板原则将这些模块串起来。这对于类的内部实现尤其重要,因为这会影响单元测试的覆盖能力。

只有这样每个方法的逻辑才能简单,对应的单元测试自然便于维护。作为老板的控制类或方法不必苛求单元测试,可酌情选择是否单元测试,因为控制是少数派,且实质逻辑已经被分摊到模块中。

逻辑与外部IO分离

这是单一职责的延申,数据的加载、处理与输出是可以作为独立的三个职责的。其中数据的加载和输出往往与外部环境依赖有关,本身的测试意义不大,即便测试也不能到处运行,且测试运行效率低下。

所以我们需要将IO逻辑从处理逻辑中剥离,并放到外层的控制逻辑中去并用mock来解决。这样没有外部依赖的处理逻辑——核心,将得到简化,从而单元测试得到简化。

如果中间实在需要外部IO可考虑在IO处进行逻辑拆分,这样拆分后的子逻辑中就没有了IO依赖,从而得到简化。

到处运行

有时候单元测试是脱离不了环境的,如我们想验证一下 SQL 的正确性。此时建议在单元测试上应用 @Disabled 注解,以便在 mvn test 中忽略这些测试,从而保证测试可以到处运行。

@Autowired

请尽量避免对框架的依赖,如 spring 的 @Autowired 注入机制,这会巨幅增加单元测试的构建难度,巨幅增加单元测试的耗时,因为这会对 mock 对象的注入造成困难。

建议,使用构造注入代替属性注入,这样就可以摆脱对 spring 的依赖。

标签:逻辑,依赖,IO,外部,单元测试,认为,测试,容易
来源: https://www.cnblogs.com/llxxbb/p/15777555.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有