写单元测试，没你想得那么简单!

前言

单元测试是什么我们就简单介绍一下：

单元测试是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。

接下来是本人对单元测试的理解和实践。里面没有废话，希望每句话能说到你心坎里。

原则：只测自己

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

这一原则的动机

便于定位

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

不重复，降低复杂度

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

实践与建议

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

分层开发

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

单一职责

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

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

逻辑与外部IO分离

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

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

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

到处运行

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

@Autowired

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

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

补充

下面是一份非常优质的学习资源，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

以上软件测试资料需要的可以私信我都可以免费获取

这还有一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中资料包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。