记一次 Mockito.mockStatic 泄漏导致的单元测试偶发报错排查过程

最新推荐文章于 2024-10-16 09:45:00 发布

wuweijie@apache.org

最新推荐文章于 2024-10-16 09:45:00 发布

阅读量3.7k

点赞数 2

分类专栏：踩坑 Java Apache ShardingSphere 文章标签：单元测试 java 开发语言 unit testing Mockito

本文链接：https://blog.csdn.net/wu_weijie/article/details/125759460

版权

Java 同时被 3 个专栏收录

24 篇文章 0 订阅

订阅专栏

踩坑

15 篇文章 0 订阅

订阅专栏

Apache ShardingSphere

12 篇文章 0 订阅

订阅专栏

文章讲述了在ApacheShardingSphere项目中，由于Mockito.mockStatic使用后未正确释放，导致单元测试偶发性失败的问题。作者通过排查和调试，发现静态方法mock的生命周期管理问题，并提供了修复方案和代码规范更新。

摘要由CSDN通过智能技术生成

相信用 Java 写过单元测试的读者们对 Mockito 不会陌生。至于 Mockito 是什么，为什么要用 Mockito，本文不再赘述。本文记录了一次在 Apache ShardingSphere 项目中，由 Mockito.mockStatic 使用不当导致的单元测试偶发报错排查过程。

文章目录

前言

Mockito 自 3.4.0 起新增了一个方法 Mockito.mockStatic，支持对静态方法 mock。

本人也曾在 Stack Overflow 上回答过一个问题，展示了我在 Apache ShardingSphere 的单元测试代码中使用 Mockito.mockStatic mock 单例的案例，对 Mockito.mockStatic 方法不是特别熟悉的同学可以了解一下：
如何使用 Mockito mock 单例 Mocking a singleton with mockito

mockStatic 使用有哪些注意实现？我们查看一下 Mockito 官方文档的说明：48. Mocking static methods (since 3.4.0)

When using the inline mock maker, it is possible to mock static method invocations within the current thread and a user-defined scope. This way, Mockito assures that concurrently and sequentially running tests do not interfere. To make sure a static mock remains temporary, it is recommended to define the scope within a try-with-resources construct.

大致的意思是：mockStatic 方法作用范围是当前线程和用户定义的作用域。为确保 mockStatic 只是临时生效，建议使用 try-with-resources 代码块包裹 mockStatic。
解读 Mockito 文档提供的示例：

assertEquals("foo", Foo.method()); // 静态方法 Foo.method() 原本行为
try (MockedStatic mocked = mockStatic(Foo.class)) { // 对 Foo 类进行 mockStatic 
    mocked.when(Foo::method).thenReturn("bar"); // 通过 mock 改变静态方法 Foo.method() 行为
    assertEquals("bar", Foo.method()); // 进行测试断言
    mocked.verify(Foo::method);
}
assertEquals("foo", Foo.method()); // 离开 mockStatic 作用域，Foo.method() 恢复原本行为

现在我们思考下，如果 mockStatic 方法没有被包裹在 try-with-resources 代码块中，也没有手动关闭 MockedStatic 对象，会发生什么事情？

根据文档的描述，如果没有关闭 mockStatic 的话，是不是被 mock 的静态类在这条线程上的行为会一直被改变？

Apache ShardingSphere 的单元测试曾出现过因 Mockito.mockStatic 使用后没有释放，导致单元测试偶发失败的问题。

排查过程

Apache ShardingSphere 会通过 GitHub Actions 对每个 PR 或合并到 master 的 commit 运行 CI——标准的 Maven clean install 流程，install 过程中就包括运行单元测试。

有段时间，ShardingSphere 的 CI 偶尔会失败一下，问了一下其他也在参与 ShardingSphere 开发的同学，本地 install 或执行单元测试也有可能会失败。

在这里插入图片描述
https://github.com/apache/shardingsphere/actions/workflows/ci.yml?query=branch%3Amaster+created%3A<2022-07-13+is%3Afailure

由于时间久远，GitHub Actions 的日志已经被清理了。

一个项目的单元测试如果不能保证稳定通过，那肯定是 测试代码有问题 或者 生产代码存在隐患。

问题复现

来看 ShardingSphere infra-common 模块下的一个单元测试，ShardingSphereMetaDataTest 中有一个用例如下：

@Test
public void assertGetMySQLDefaultSchema() throws SQLException {
    MySQLDatabaseType databaseType = new MySQLDatabaseType();
    ShardingSphereDatabase actual = ShardingSphereDatabase.create("foo_db", databaseType, Collections.singletonMap("", databaseType), mock(DataSourceProvidedDatabaseConfiguration.class), new ConfigurationProperties(new Properties()), mock(InstanceContext.class));
    assertNotNull(actual.getSchema("foo_db"));
}

单独运行这个测试用例，是通过的。
在这里插入图片描述
但是，如果运行 infra-common 模块下的所有测试，这个用例就会失败。

其中，ShardingSphereDatabase.create 最终调用的静态方法大致如下，代码中只有正常返回一个 ShardingSphereDatabase 实例或抛出异常两种可能，不存在返回 null 的情况。

private static ShardingSphereDatabase create(final String name, final DatabaseType protocolType, final DatabaseConfiguration databaseConfig, final Collection<ShardingSphereRule> rules, final Map<String, ShardingSphereSchema> schemas) {
    // 省略中间过程代码
    return new ShardingSphereDatabase(name, protocolType, resourceMetaData, ruleMetaData, schemas);
}

但是，这么简单的一段单元测试确实就报了空指针，而且还是 actual（静态方法 ShardingSphereDatabase.create 的返回结果）为 null。

java.lang.NullPointerException: Cannot invoke "org.apache.shardingsphere.infra.metadata.database.ShardingSphereDatabase.getSchema(String)" because "actual" is null
	at org.apache.shardingsphere.infra.metadata.ShardingSphereMetaDataTest.assertGetMySQLDefaultSchema(ShardingSphereMetaDataTest.java:109)

从代码上看，一个没有可能返回 null 的静态方法，却在单元测试返回了 null，不理解！

由于本地环境暂时能够持续必现问题，可以打断点 Debug 一下。

失败是偶发而不是必现的原因是：一个模块下的单元测试的运行顺序不是恒定的。 有些可能污染其他测试用例的测试代码，恰好其运行顺序比较靠后，测试运行表现为正常通过。

曾经我也解决过另一个受单元测试执行顺序影响的偶发问题，具体排查可以见我之前的文章：记一次 ThreadLocal 泄漏导致的 shardingsphere-jdbc-core 单元测试偶发失败的排查与修复

调试代码

打上断点，运行模块全量测试，跑到了断言失败前的代码。
来一个快速表达式计算，确实是 ShardingSphereDatabase.create 方法返回了 null。
在这里插入图片描述

那进入方法内部看看：

发现端倪 & 解决

奇怪的现象出现了！可以看下面这个动图：
在这里插入图片描述
进入 ShardingSphereDatabaes.create 方法后，点击 Step Into，正常情况下应该继续进入 create 方法第一行代码的 DatabaseRulesBuilder.build 方法，但是，调试器却直接跳到了 create 方法的 return，并且点击 Step Into 也没有继续进入 create 方法！