深入理解单元测试

最新推荐文章于 2024-10-30 15:46:58 发布

原创最新推荐文章于 2024-10-30 15:46:58 发布 · 7.5k 阅读

1 ·

CC 4.0 BY-SA版权

Java 专栏收录该内容

59 篇文章

订阅专栏

本文探讨了单元测试的重要性，解答了常见的误解，如写单元测试是否浪费时间、能否减少bug及重构时的负担。深入介绍了单元测试作为代码文档和重构安全网的角色，以及如何利用TDD方法论和Mockito框架进行高效测试。

作为一个程序员，或多或少听说过单元测试，但很多小伙伴还没有在实际项目中用到。究其原因，可能是对单元测试有一些误解，比如：

写单元测试需要花费更多的时间，我每天写产品代码都要加班，哪来时间写测试；
写单元测试收益不大，还不是一样有bug；
写单元测试有负担，改产品代码的结构，还得去改测试代码。

先尝试解答这几个问题。

写单元测试会花费更多的时间，这点描述其实不准确。准确地说，写单元测试需要花费更多写代码的时间，这点没什么可说的，毕竟要多写一些测试代码。但一个程序员，做一个需求的时候，花在纯写代码的时间其实不多。你得理以前代码的逻辑，设计类和方法，然后才是写代码，写完了再手动测试，可能有bug还要去debug，再修复，再测试。真正写代码的时间，其实是很少的。使用单元测试虽然可能占用了更多写代码的时间，但它可以帮你缩短其它时间，会让你做这个需求花费的总时间更少。
写单元测试会有bug吗？当然可能有了，我们是无法做到真正的bug free的，但是单元测试写好了，可以显著减小bug的数量。因为写单元测试发现bug的成本是非常低的，它可以在开发阶段就发现bug，而且可以测试很多边界的条件。但如果你对需求和业务的认知本来都是有误的，这是单元测试解决不了的，自然会产生bug。话说回来，写单元测试的收益远不止发现bug这么简单，它还具有代码文档的功能，以及重构的安全网存在。甚至它还可以帮你理需求，设计代码。
改产品代码需要维护对应的测试代码，这确实是带来了额外的成本。不过借助编辑器的重构功能，可以比较方便地批量修改需要修改的地方，其实代价没有想象中的那么大。而且重构后，再跑一遍单元测试，看哪些挂掉了，可以double-check你改的产品代码有没有问题。如果我们把单元测试当成是产品代码的文档来看，大概就更能够接受这个维护的成本了。

为什么写单元测试

前面提到，单元测试有很多功能。个人觉得单元测试最大的作用是“代码文档”和“重构安全网”。毕竟软件开发的漫长过程中，总少不了修修改改。如果没有足够的测试，改一段代码就像是在排地雷，改完后心里也总是打鼓，上线前需要先默默拜个神，生怕触发了什么bug。

但如果有足够的测试（不只是单元测试），改完代码后可以跑一遍测试，看哪些挂掉了，是不是自己的改动导致的，该怎么修好测试。这样心里就有底气多了。

要知道，代码写出来是给人看的。而测试比产品代码更友好，因为它简单，直白，站在使用者的视角来描述，所以如果想要了解一段产品代码具有什么功能，看它的单元测试会更直观，更舒服。

很多团队会做测试，但绝大多数测试的工作是在开发后，由专门的测试同学去负责端到端的测试或者API测试。其实端到端的测试成本是非常大的，尤其是对于某些边界条件，构造数据和场景是非常麻烦的。而且一旦发现了bug，再去沟通，修改，提交，部署，需要花费很多时间。

而单元测试最大的优势就是“成本低”，想要测试产品代码的每个分支都比较容易，而且单元测试一般是开发同学自己写，可以用最小的时间发现bug，用最低的成本修改bug。

什么是单元测试

测试金字塔

并不是所有测试都是单元测试，测试其实分成很多种。业界比较广泛传播的“测试金字塔”描述了它们的区别和关系：
在这里插入图片描述
从测试金字塔模型来看，越在底层的测试，覆盖面应该更广，成本更低。单元测试处于测试金字塔的最低端，是整个测试金字塔的基础。

单元测试的特点

单元测试就像它的名字一样，“单元”（Unit），足够小，足够快，无依赖。单元测试只测你想测的那部分产品代码的逻辑，一个单元测试应该只测一个简单的业务逻辑。一般来说，运行一个单元测试是很快的，基本上在几毫秒到几十毫秒之间。如果有依赖的类，可以mock其他类，消除外部依赖。

什么不是单元测试？

很多同学容易将其他测试与单元测试搞混，最常见的是会启动Spring上下文的集成测试。比如使用@SpringBootTest注解可以启动Spring上下文，这可以测试依赖是否正常注入等Spring的功能，但运行一次需要耗费很多时间（因为要启动Spring上下文），也并不是真正的“单元测试”，因为它依赖了Spring框架。

如何写单元测试

那具体如何写单元测试呢？我们业界有一个叫做TDD（测试驱动开发）的方法论。TDD的核心在于“驱动”二字，它的理念是从测试视角出发，通过测试驱动出来产品代码。而在测试金字塔中，单元测试与开发人员最息息相关，所以这里的“测试”一般是指的单元测试。

TDD大概分这几个步骤：

理清需求
设计类和方法的出参和入参
写测试代码
驱动出产品代码
重构，循环3-5步。

首先要理清楚需求，因为只有理清楚了需求，才能保证我们使用TDD驱动出来的代码是跟业务期望的一致的。然后第二步是设计类和方法的过程，也称为Task List。这一步可以设计好类与类之间的关系，方法的出参和入参。其实不使用TDD也会有前面这两个步骤，只不过使用TDD的话，可以帮助你更好地从业务视角出发，先把该设计的东西都设计好，避免直接上手写代码，写到一半的时候觉得不对，再去改。

3-5步其实是一个循环的过程。因为刚开始写代码可能并没有太注意代码的格式、风格、性能，一气呵成写得比较快，让测试通过。等测试通过后，可以回过头来重构一下之前写的代码，重构后再跑一遍所有的单元测试，看是否有挂掉的单元测试，以此来检测重构是否对期望的输入输出有影响。

Mockito的基本用法

Mockito是Java语言非常主流的一个框架，自己使用起来感觉也比较好用。所以本文以Mockito为例，来介绍一下常用的方法。

设置Mockito环境

要使用Mockito，首先得在测试类里面设置好Mockito环境。这是为了能够让单元测试框架（本文主要介绍JUnit）能够识别和使用Mockito。

熟悉JUnit的小伙伴一定知道，JUnit使用了@RunWith注解来声明一个“运行器”。Mockito也有相应的启动器：

MockitoAnnotations.initMocks(this)

mock

mock，即mock一个对象。比如一些service和mapper等bean就可以通过@Mock注解来mock。

@Mock
private CommonService commonService;

InjectMocks

使用@InjectMocks注解，可以将mock的对象自动注入要测试的对象。这在Spring等使用自动注入的框架里用得非常广泛。比如我们要测试一个service的实现，就可以这样子写：

@InjectMocks
ValidateService validateService = new ValidateServiceImpl();

打桩

所谓打桩，其实就是mock的一个过程。我们给定期望的输入和输入，mock的对象就能够如我们期望的那样工作。

打桩有两种写法，一种是传统的写法，一种是BDD（Behavior-Driven Development (行为驱动开发)）的写法。

我们先看看传统的写法，传统的写法主要用Mockito类的方法。基本是when-then-invoke-verify形式。

when(phoneBookRepository.contains(momContactName))
  .thenReturn(false);
 
phoneBookService.register(momContactName, momPhoneNumber);
 
verify(phoneBookRepository)
  .insert(momContactName, momPhoneNumber);

BDD写法主要是用BDDMockito类的方法，看起来是given–will-invoke-then的形式。

given(phoneBookRepository.contains(momContactName))
  .willReturn(false);
 
phoneBookService.register(momContactName, momPhoneNumber);
 
then(phoneBookRepository)
  .should()
  .insert(momContactName, momPhoneNumber);