DragonWell21 单元测试开发指南

前言

本文旨在为DragonWell21项目中的虚拟机开发提供单元测试编写指南。单元测试是保证代码质量的重要手段，良好的测试实践能够显著提升开发效率和代码可靠性。本文将详细介绍如何编写高质量的单元测试。

测试类型选择

测试根据对JVM的依赖程度分为三类，开发者应根据测试需求选择最轻量级的类型：

1. 基础测试(TEST)：不依赖JVM环境，适合纯逻辑测试
2. VM测试(TEST_VM)：需要初始化JVM但不会破坏其状态
3. 独立VM测试(TEST_OTHER_VM)：需要全新JVM或会破坏JVM状态

选择原则是：能用简单类型就不用复杂类型，因为越复杂的测试执行越慢。

优秀测试的特性

隔离性

测试之间应该相互独立，不产生可见的副作用。由于所有TEST_VM测试共享同一个JVM实例，如果测试会显著改变JVM状态，应考虑使用TEST_OTHER_VM。

原子性与自包含性

每个测试应该专注于验证特定功能点，但同时要完整覆盖该功能的各个方面。例如测试一个方法时：

• 测试正常输入
• 测试边界条件
• 测试异常情况

可重复性

测试结果应该是确定性的，避免偶发失败。虽然并发环境下完全确定性很难保证，但应尽可能提高测试的稳定性。

信息丰富性

测试失败时应提供足够的信息帮助定位问题，但也要避免正常情况下的信息过载。可以通过：

• 在断言中添加有意义的错误信息
• 在循环测试中输出迭代信息
• 记录关键内部状态

断言使用规范

断言选择

优先使用EXPECT而非ASSERT，除非后续测试无法继续。EXPECT允许测试继续执行并报告更多错误，有助于问题定位。

参数顺序

在相等断言中，期望值应作为第一个参数。这与GoogleTest的约定一致，且对NULL检测有特殊处理。

特殊类型比较

• 浮点数：使用EXPECT_FLOAT_EQ/EXPECT_DOUBLE_EQ或EXPECT_NEAR
• C字符串：使用EXPECT_STREQ/EXPECT_STRNE系列宏

错误信息

利用<<操作符添加有意义的错误信息，但避免冗余。例如：

EXPECT_EQ(expected, actual) << "Iteration: " << i;

命名与组织规范

测试组命名

测试组名采用CamelCase，反映被测试的类或子系统。例如：

• 类Foo的测试组：Foo
• G1 GC测试组：G1GC

文件命名

测试文件必须以"test_"开头，".cpp"结尾。位置应与被测试代码的路径对应：

• foo/bar/baz.cpp的测试放在foo/bar/test_baz.cpp
• 跨类测试按子系统组织在对应目录

测试用例命名

测试名采用small_snake_case，清晰描述测试内容。例如：

• foo_return_0_if_name_is_null
• humongous_objects_can_not_be_moved_by_young_gc

测试固件

测试固件类名应添加"Test"后缀，如FooTest，以避免命名冲突。

特殊场景处理

非公开成员访问

通过显式声明友元类访问非公开成员，不建议使用GoogleTest的FRIEND_TEST宏。可以考虑：

1. 将测试固件类声明为友元
2. 创建专门的测试辅助类
3. 适当放宽成员可见性

平台相关测试

使用#ifdef保护平台相关代码，并在文件名中体现平台信息，如test_foo_linux.cpp。

JVM参数处理

当前版本限制：

• 不支持向测试JVM传递外部参数
• 可通过_JAVA_OPTIONS环境变量设置参数
• 需要特定参数组合的测试应使用条件返回

参数恢复

修改JVM参数后必须恢复原值，可使用：

• FLAG_GUARD宏
• *FlagSetting类
• 测试固件的TearDown方法

注意FLAG_SET_*宏可能修改多个参数以保持一致性，此时应使用TEST_OTHER_VM。

测试开发建议

1. 覆盖度指标：关注分支覆盖度，确保测试全面性
2. 代码风格：测试代码遵循项目代码规范
3. 避免死亡测试：TEST_OTHER_VM中不能使用死亡测试
4. 文档参考：详细阅读GoogleTest文档掌握各种断言用法

总结

编写高质量的单元测试需要：

• 选择合适的测试类型
• 遵循命名和组织规范
• 编写具有良好特性的测试用例
• 正确处理特殊场景
• 保持代码风格一致

良好的测试实践将显著提升DragonWell21的开发质量和效率。随着项目发展，测试框架也会不断完善，开发者应关注相关更新。