FoundationDB Java 绑定测试开发指南基于 JUnit 与 ctest 的单元测试、集成测试与 Multi-Client 测试实践【免费下载链接】foundationdbFoundationDB - the open source, distributed, transactional key-value store项目地址: https://gitcode.com/gh_mirrors/fo/foundationdbFoundationDB 的 Java 绑定位于 bindings/java提供了一整套基于 JUnit 5 与 CTest 的测试体系用于在构建过程中验证绑定 API 的正确性。本文以 bindings/java/src/README.md 为骨架结合仓库中的 tests.cmake、CMakeLists.txt 及真实测试代码完整讲解如何在 Java 绑定中新增单元测试、集成测试与 Multi-Client 测试并掌握用ctest精确筛选、运行这些测试的实战方法。读完本文你将能独立为 FoundationDB Java 绑定贡献新的 JUnit 测试并理解其背后的 CMake 注册机制与集群启动流程。一、测试体系总览三类测试的边界在动手写测试之前先要理解 FoundationDB Java 绑定把测试划分为三类每类对运行环境的要求完全不同。这种划分直接体现在源码目录结构上测试类别源码目录是否需要运行中的 FDB 集群在 tests.cmake 中的变量单元测试Unit Testsrc/junit/...否JAVA_JUNIT_TESTS集成测试Integration Testsrc/integration/...是单个集群JAVA_INTEGRATION_TESTSMulti-Client 测试src/integration/...是多个集群JAVA_INTEGRATION_TESTS带Tag(MultiClient)单元测试不依赖任何运行中的数据库适合验证纯逻辑例如 Tuple 的打包/序列化、Range 查询逻辑等集成测试则需要一个真实运行的 FDB 实例Multi-Client 测试是集成测试的特例必须同时运行多个集群用于验证多集群客户端行为。这种划分意味着单元测试可以在任何构建机器上快速执行而集成测试则与集群生命周期管理深度绑定。二、添加单元测试三步走原文档给出的单元测试添加流程非常简洁共三步编写测试将测试文件路径以src为起点的相对路径追加到tests.cmake中例如src/junit/com/apple/foundationdb/tuple/ArrayUtilTests.java重新运行构建cmake以及make/xcode/ninja均需重新执行。这里的关键在于第 2 步tests.cmake中的JAVA_JUNIT_TESTS变量是构建系统发现单元测试的唯一入口。查看仓库中的 tests.cmake当前注册的单元测试如下set(JAVA_JUNIT_TESTS src/junit/com/apple/foundationdb/tuple/ArrayUtilSortTest.java src/junit/com/apple/foundationdb/tuple/ArrayUtilTest.java src/junit/com/apple/foundationdb/tuple/ByteArrayUtilTest.java src/junit/com/apple/foundationdb/tuple/TupleComparisonTest.java src/junit/com/apple/foundationdb/tuple/TuplePackingTest.java src/junit/com/apple/foundationdb/tuple/TupleSerializationTest.java src/junit/com/apple/foundationdb/RangeQueryTest.java src/junit/com/apple/foundationdb/EventKeeperTest.java )注意几点细节路径必须以src为起点即src/junit/...而不是相对于tests.cmake所在目录的路径测试类必须放在src/junit目录下tests.cmake 中的注释明确要求make sure that they are in the src/junit folder除了测试文件本身单元测试还会用到一些辅助资源JUnit 规则、工具类它们不直接作为测试运行需要放进单独的JUNIT_RESOURCES变量当前包括 FDBLibraryRule.java用于加载 FDB 客户端库和 FakeFDBTransaction.java用于模拟事务对象。以一个真实的单元测试为例TuplePackingTest.java 通过RegisterExtension引入FDBLibraryRule来加载本地客户端库并使用ParameterizedTestMethodSource批量验证 Tuple 打包逻辑——这是编写不依赖数据库的纯逻辑测试的典型范式。修改完tests.cmake后务必重新执行 CMake 配置cmake和构建make、ninja或 Xcode 的xcodebuild因为测试文件的清单是在 CMake 配置阶段固化到构建产物中的仅重新编译不会让新测试生效。三、添加集成测试在真实集群上验证集成测试的添加流程与单元测试几乎一致同样三步用 JUnit 编写测试将测试路径追加到tests.cmake的JAVA_INTEGRATION_TESTS例如src/integration/com/apple/foundationdb/DirectoryTest.java重新运行cmake与构建。当前 tests.cmake 中注册的集成测试包括DirectoryTest、RangeQueryIntegrationTest、TransactionIntegrationTest、WatchesIntegrationTest等 11 个文件对应的辅助资源JAVA_INTEGRATION_RESOURCES中有两个关键类RequiresDatabase.java一个同时实现ExecutionCondition与BeforeAllCallback的 JUnit 扩展作为数据库健康检查闸门MultiClientHelper.javaMulti-Client 测试专用的BeforeAllCallback扩展负责按FDB_CLUSTERS环境变量打开多个集群连接。集成测试与单元测试最大的差异是运行时环境。以 DirectoryTest.java 为例它在类上标注ExtendWith(RequiresDatabase.class)并在beforeAll阶段通过FDB.selectAPIVersion(ApiVersion.LATEST)打开默认集群、执行一次带超时的读操作来探测数据库是否可用。RequiresDatabase的实现细节RequiresDatabase.java揭示了三层保护机制系统属性run.integration.testsfalse可直接跳过所有集成测试evaluateExecutionCondition返回disabled若未禁用beforeAll会尝试连接数据库每次事务设置 5 秒超时最多重试 10 次、间隔 500ms连接失败则调用Assertions.fail快速失败避免长时间挂起等待网络超时源码注释明确指出这是针对 CI 负载较高时单节点集群仍在引导的情况设计的。四、运行测试ctest 的筛选艺术构建完成后所有测试都通过 CTest 暴露出来。原文档给出了三个最核心的命令均需在${BUILD_DIR}/bindings/java目录下执行命令作用ctest .运行全部单元测试与集成测试ctest -E integration跳过所有集成测试只跑单元测试ctest -R integration只运行集成测试-E是正则表达式排除Exclude-R是正则表达式匹配Regex二者配合可以非常精细地控制测试范围。例如从${BUILD_DIR}顶层目录运行时为避免混入原生逻辑的测试可以执行ctest . -R java-unit只看 Java 单元测试这条命令在 CMakeLists.txt 的注释中有明确说明。提示原文档还提到 CTest 有大量其他实用命令详细语法可查阅 CTest 官方文档本文不展开。测试在 CTest 中如何注册理解上述命令背后的机制需要看 CMakeLists.txt 中的测试注册逻辑。Java 测试受三个 CMake 开关控制set(RUN_JAVA_TESTS ON CACHE BOOL Run Java unit tests) set(RUN_JUNIT_TESTS OFF CACHE BOOL Compile and run junit tests) set(RUN_JAVA_INTEGRATION_TESTS OFF CACHE BOOL Compile and run integration tests)当RUN_JUNIT_TESTS或RUN_JAVA_INTEGRATION_TESTS开启时构建系统会先下载 JUnit 5.7.1 平台相关 jar 包junit-jupiter-engine/api/params、junit-platform-console/commons/engine/launcher 等见 CMakeLists.txt下载到packages目录并校验 SHA-256然后通过add_jar把测试源码与 fdb-java 主 jar 打包成fdb-junit、fdb-integration两个测试 jar最后注册 CTest 用例。单元测试注册为一个名为java-unit的 CTest 用例通过org.junit.platform.console.ConsoleLauncher --scan-classpath扫描测试类路径来执行集成测试则注册了三个用例java-integration由add_fdbclient_test创建启动单个临时集群后运行 ConsoleLauncher并排除MultiClient标签-T MultiClientjava-multi-integration由add_multi_fdbclient_test创建启动3 个集群后运行只执行带MultiClient标签的测试-t MultiClientjava-integration-external-client同样单个集群但额外传入--configexternal_client_library.../libfdb_c_external.so用于验证外部客户端库场景。临时集群从哪里来add_fdbclient_test与add_multi_fdbclient_test定义在 cmake/AddFdbTest.cmake 中。前者通过python -m fdb_test_runner.tmp_cluster --build-dir ${CMAKE_BINARY_DIR}启动单集群默认超时 300 秒开启 sanitizer 时为 1200 秒见 AddFdbTest.cmake后者通过python -m fdb_test_runner.tmp_multi_cluster --clusters 3启动 3 个独立集群且测试超时固定为60 秒见 AddFdbTest.cmake——这直接解释了原文档中Multi-Client 测试必须尽量短小或配置更长超时的警告来源。五、Multi-Client 测试多集群场景的专项实践Multi-Client 测试用于验证多个客户端连接多个集群的场景例如多集群客户端、跨集群数据读写。原文档给出了三条硬性要求仓库源码逐条印证用Tag(MultiClient)标记测试所有 Multi-Client 专属测试必须打上该标签确保在普通集成测试中被排除。这一点在 BasicMultiClientIntegrationTest.java 的类注释中有明确说明且java-integration用例正是通过-T MultiClient排除它们而java-multi-integration通过-t MultiClient只运行它们。引入并注册MultiClientHelper扩展MultiClientHelper是一个BeforeAllCallback在beforeAll阶段读取环境变量FDB_CLUSTERS多个集群连接文件路径用分号;分隔见 MultiClientHelper.java并通过fdb.open(path)依次打开所有集群的Database句柄。测试通过clientHelper.openDatabases(fdb)获取集群集合测试结束后由 helper 统一关闭。将测试类加入JAVA_INTEGRATION_TESTS列表Multi-Client 测试类仍然位于src/integration目录必须像普通集成测试一样在 tests.cmake 中登记如BasicMultiClientIntegrationTest、CycleMultiClientIntegrationTest、SidebandMultiThreadClientTest等。原文档还强调了一个极易踩坑的运维细节启动和停止 3 个独立集群非常耗时如果底层测试本身运行时间长ctest 会在超时后直接杀死测试进程此时无法保证 FDB 集群被正常关闭可能遗留孤儿进程或脏数据。因此 Multi-Client 测试务必保持短小精悍要么严格控制每个用例的执行时间要么为测试配置更长的超时。作为参照BasicMultiClientIntegrationTest.java 展示了标准的写法RegisterExtension静态注册MultiClientHelper测试方法上标注Tag(MultiClient)循环 25 轮、每轮遍历所有集群数据库执行 set/get 并通过Assertions.assertEquals校验写入结果每轮之间Thread.sleep(200)控制节奏——这正是小而快设计原则的体现。六、集成测试编写的最佳实践共享集群下的隔离设计从 CMakeLists.txt 的注释中可以提炼出集成测试的两个关键设计约束这是任何新增集成测试都必须遵守的所有集成测试共享同一个 FDB 集群。因此测试绝不能假设数据库是空的也不能假设某个 key 一定不存在。原文档与 CMake 注释给出的建议是为每个测试生成随机 key 前缀、使用目录层Directory Layer创建唯一路径的子空间来隔离数据。集成测试可能并行执行。应当尽量让测试具备并行安全能力使用唯一 key 范围因为合理的假设是单个服务器会被多个测试共享且可能被并发访问。这与单测不同单测完全独立无需考虑共享状态。这两条约束意味着写集成测试时优先使用 Subspace 或 DirectoryLayer 来划定专属数据区域并在测试结束后清理参考 DirectoryTest.java 中创建目录后finally块里dir.remove的清理模式。七、常见问题与排查建议现象原因与对策新增测试后ctest里看不到tests.cmake修改后未重新执行cmake配置与构建或路径未以src/开头、文件不在src/junit/src/integration目录集成测试被跳过设置了系统属性run.integration.testsfalseRequiresDatabase的兜底开关或当前没有可用集群集成测试在连接阶段快速失败集群未启动或仍在引导RequiresDatabase会在 10 次重试共约 5 秒量级后 fail-fastMulti-Client 测试被 ctest 超时杀死java-multi-integration的 CTest 超时固定为 60 秒见 AddFdbTest.cmake请压缩用例时长只想跑单元测试却混入了原生测试从${BUILD_DIR}顶层改用ctest . -R java-unit精确过滤使用 sanitizer 构建CMake 会直接拒绝运行 Java 测试并给出警告Cannot run java tests with sanitizer builds见 CMakeLists.txt结语FoundationDB Java 绑定的测试体系以目录约定 CMake 登记 ctest 调度三件事为核心目录约定决定了测试的类别src/junit单测、src/integration集成与多客户端测试tests.cmake中的JAVA_JUNIT_TESTS、JAVA_INTEGRATION_TESTS及配套资源变量是构建系统发现测试的唯一入口而 ctest 的-R/-E正则筛选则让开发者可以按需运行任意子集。理解这三层机制后无论是为 Tuple 层补充单元测试还是为目录层、范围查询等能力贡献集成测试或是编写跨集群的 Multi-Client 用例都能做到写好即注册、注册即运行并与 FoundationDB 现有的 CI 与 Joshua 测试体系无缝衔接。【免费下载链接】foundationdbFoundationDB - the open source, distributed, transactional key-value store项目地址: https://gitcode.com/gh_mirrors/fo/foundationdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/21 2:18:55 · 阅读 1.2k FoundationDB Java 绑定测试开发指南：基于 JUnit 与 ctest 的单元测试、集成测试与 Multi-Client 测试实践
FoundationDB Java 绑定测试开发指南基于 JUnit 与 ctest 的单元测试、集成测试与 Multi-Client 测试实践【免费下载链接】foundationdbFoundationDB - the open source, distributed, transactional key-value store项目地址: https://gitcode.com/gh_mirrors/fo/foundationdbFoundationDB 的 Java 绑定位于 bindings/java提供了一整套基于 JUnit 5 与 CTest 的测试体系用于在构建过程中验证绑定 API 的正确性。本文以 bindings/java/src/README.md 为骨架结合仓库中的 tests.cmake、CMakeLists.txt 及真实测试代码完整讲解如何在 Java 绑定中新增单元测试、集成测试与 Multi-Client 测试并掌握用ctest精确筛选、运行这些测试的实战方法。读完本文你将能独立为 FoundationDB Java 绑定贡献新的 JUnit 测试并理解其背后的 CMake 注册机制与集群启动流程。一、测试体系总览三类测试的边界在动手写测试之前先要理解 FoundationDB Java 绑定把测试划分为三类每类对运行环境的要求完全不同。这种划分直接体现在源码目录结构上测试类别源码目录是否需要运行中的 FDB 集群在 tests.cmake 中的变量单元测试Unit Testsrc/junit/...否JAVA_JUNIT_TESTS集成测试Integration Testsrc/integration/...是单个集群JAVA_INTEGRATION_TESTSMulti-Client 测试src/integration/...是多个集群JAVA_INTEGRATION_TESTS带Tag(MultiClient)单元测试不依赖任何运行中的数据库适合验证纯逻辑例如 Tuple 的打包/序列化、Range 查询逻辑等集成测试则需要一个真实运行的 FDB 实例Multi-Client 测试是集成测试的特例必须同时运行多个集群用于验证多集群客户端行为。这种划分意味着单元测试可以在任何构建机器上快速执行而集成测试则与集群生命周期管理深度绑定。二、添加单元测试三步走原文档给出的单元测试添加流程非常简洁共三步编写测试将测试文件路径以src为起点的相对路径追加到tests.cmake中例如src/junit/com/apple/foundationdb/tuple/ArrayUtilTests.java重新运行构建cmake以及make/xcode/ninja均需重新执行。这里的关键在于第 2 步tests.cmake中的JAVA_JUNIT_TESTS变量是构建系统发现单元测试的唯一入口。查看仓库中的 tests.cmake当前注册的单元测试如下set(JAVA_JUNIT_TESTS src/junit/com/apple/foundationdb/tuple/ArrayUtilSortTest.java src/junit/com/apple/foundationdb/tuple/ArrayUtilTest.java src/junit/com/apple/foundationdb/tuple/ByteArrayUtilTest.java src/junit/com/apple/foundationdb/tuple/TupleComparisonTest.java src/junit/com/apple/foundationdb/tuple/TuplePackingTest.java src/junit/com/apple/foundationdb/tuple/TupleSerializationTest.java src/junit/com/apple/foundationdb/RangeQueryTest.java src/junit/com/apple/foundationdb/EventKeeperTest.java )注意几点细节路径必须以src为起点即src/junit/...而不是相对于tests.cmake所在目录的路径测试类必须放在src/junit目录下tests.cmake 中的注释明确要求make sure that they are in the src/junit folder除了测试文件本身单元测试还会用到一些辅助资源JUnit 规则、工具类它们不直接作为测试运行需要放进单独的JUNIT_RESOURCES变量当前包括 FDBLibraryRule.java用于加载 FDB 客户端库和 FakeFDBTransaction.java用于模拟事务对象。以一个真实的单元测试为例TuplePackingTest.java 通过RegisterExtension引入FDBLibraryRule来加载本地客户端库并使用ParameterizedTestMethodSource批量验证 Tuple 打包逻辑——这是编写不依赖数据库的纯逻辑测试的典型范式。修改完tests.cmake后务必重新执行 CMake 配置cmake和构建make、ninja或 Xcode 的xcodebuild因为测试文件的清单是在 CMake 配置阶段固化到构建产物中的仅重新编译不会让新测试生效。三、添加集成测试在真实集群上验证集成测试的添加流程与单元测试几乎一致同样三步用 JUnit 编写测试将测试路径追加到tests.cmake的JAVA_INTEGRATION_TESTS例如src/integration/com/apple/foundationdb/DirectoryTest.java重新运行cmake与构建。当前 tests.cmake 中注册的集成测试包括DirectoryTest、RangeQueryIntegrationTest、TransactionIntegrationTest、WatchesIntegrationTest等 11 个文件对应的辅助资源JAVA_INTEGRATION_RESOURCES中有两个关键类RequiresDatabase.java一个同时实现ExecutionCondition与BeforeAllCallback的 JUnit 扩展作为数据库健康检查闸门MultiClientHelper.javaMulti-Client 测试专用的BeforeAllCallback扩展负责按FDB_CLUSTERS环境变量打开多个集群连接。集成测试与单元测试最大的差异是运行时环境。以 DirectoryTest.java 为例它在类上标注ExtendWith(RequiresDatabase.class)并在beforeAll阶段通过FDB.selectAPIVersion(ApiVersion.LATEST)打开默认集群、执行一次带超时的读操作来探测数据库是否可用。RequiresDatabase的实现细节RequiresDatabase.java揭示了三层保护机制系统属性run.integration.testsfalse可直接跳过所有集成测试evaluateExecutionCondition返回disabled若未禁用beforeAll会尝试连接数据库每次事务设置 5 秒超时最多重试 10 次、间隔 500ms连接失败则调用Assertions.fail快速失败避免长时间挂起等待网络超时源码注释明确指出这是针对 CI 负载较高时单节点集群仍在引导的情况设计的。四、运行测试ctest 的筛选艺术构建完成后所有测试都通过 CTest 暴露出来。原文档给出了三个最核心的命令均需在${BUILD_DIR}/bindings/java目录下执行命令作用ctest .运行全部单元测试与集成测试ctest -E integration跳过所有集成测试只跑单元测试ctest -R integration只运行集成测试-E是正则表达式排除Exclude-R是正则表达式匹配Regex二者配合可以非常精细地控制测试范围。例如从${BUILD_DIR}顶层目录运行时为避免混入原生逻辑的测试可以执行ctest . -R java-unit只看 Java 单元测试这条命令在 CMakeLists.txt 的注释中有明确说明。提示原文档还提到 CTest 有大量其他实用命令详细语法可查阅 CTest 官方文档本文不展开。测试在 CTest 中如何注册理解上述命令背后的机制需要看 CMakeLists.txt 中的测试注册逻辑。Java 测试受三个 CMake 开关控制set(RUN_JAVA_TESTS ON CACHE BOOL Run Java unit tests) set(RUN_JUNIT_TESTS OFF CACHE BOOL Compile and run junit tests) set(RUN_JAVA_INTEGRATION_TESTS OFF CACHE BOOL Compile and run integration tests)当RUN_JUNIT_TESTS或RUN_JAVA_INTEGRATION_TESTS开启时构建系统会先下载 JUnit 5.7.1 平台相关 jar 包junit-jupiter-engine/api/params、junit-platform-console/commons/engine/launcher 等见 CMakeLists.txt下载到packages目录并校验 SHA-256然后通过add_jar把测试源码与 fdb-java 主 jar 打包成fdb-junit、fdb-integration两个测试 jar最后注册 CTest 用例。单元测试注册为一个名为java-unit的 CTest 用例通过org.junit.platform.console.ConsoleLauncher --scan-classpath扫描测试类路径来执行集成测试则注册了三个用例java-integration由add_fdbclient_test创建启动单个临时集群后运行 ConsoleLauncher并排除MultiClient标签-T MultiClientjava-multi-integration由add_multi_fdbclient_test创建启动3 个集群后运行只执行带MultiClient标签的测试-t MultiClientjava-integration-external-client同样单个集群但额外传入--configexternal_client_library.../libfdb_c_external.so用于验证外部客户端库场景。临时集群从哪里来add_fdbclient_test与add_multi_fdbclient_test定义在 cmake/AddFdbTest.cmake 中。前者通过python -m fdb_test_runner.tmp_cluster --build-dir ${CMAKE_BINARY_DIR}启动单集群默认超时 300 秒开启 sanitizer 时为 1200 秒见 AddFdbTest.cmake后者通过python -m fdb_test_runner.tmp_multi_cluster --clusters 3启动 3 个独立集群且测试超时固定为60 秒见 AddFdbTest.cmake——这直接解释了原文档中Multi-Client 测试必须尽量短小或配置更长超时的警告来源。五、Multi-Client 测试多集群场景的专项实践Multi-Client 测试用于验证多个客户端连接多个集群的场景例如多集群客户端、跨集群数据读写。原文档给出了三条硬性要求仓库源码逐条印证用Tag(MultiClient)标记测试所有 Multi-Client 专属测试必须打上该标签确保在普通集成测试中被排除。这一点在 BasicMultiClientIntegrationTest.java 的类注释中有明确说明且java-integration用例正是通过-T MultiClient排除它们而java-multi-integration通过-t MultiClient只运行它们。引入并注册MultiClientHelper扩展MultiClientHelper是一个BeforeAllCallback在beforeAll阶段读取环境变量FDB_CLUSTERS多个集群连接文件路径用分号;分隔见 MultiClientHelper.java并通过fdb.open(path)依次打开所有集群的Database句柄。测试通过clientHelper.openDatabases(fdb)获取集群集合测试结束后由 helper 统一关闭。将测试类加入JAVA_INTEGRATION_TESTS列表Multi-Client 测试类仍然位于src/integration目录必须像普通集成测试一样在 tests.cmake 中登记如BasicMultiClientIntegrationTest、CycleMultiClientIntegrationTest、SidebandMultiThreadClientTest等。原文档还强调了一个极易踩坑的运维细节启动和停止 3 个独立集群非常耗时如果底层测试本身运行时间长ctest 会在超时后直接杀死测试进程此时无法保证 FDB 集群被正常关闭可能遗留孤儿进程或脏数据。因此 Multi-Client 测试务必保持短小精悍要么严格控制每个用例的执行时间要么为测试配置更长的超时。作为参照BasicMultiClientIntegrationTest.java 展示了标准的写法RegisterExtension静态注册MultiClientHelper测试方法上标注Tag(MultiClient)循环 25 轮、每轮遍历所有集群数据库执行 set/get 并通过Assertions.assertEquals校验写入结果每轮之间Thread.sleep(200)控制节奏——这正是小而快设计原则的体现。六、集成测试编写的最佳实践共享集群下的隔离设计从 CMakeLists.txt 的注释中可以提炼出集成测试的两个关键设计约束这是任何新增集成测试都必须遵守的所有集成测试共享同一个 FDB 集群。因此测试绝不能假设数据库是空的也不能假设某个 key 一定不存在。原文档与 CMake 注释给出的建议是为每个测试生成随机 key 前缀、使用目录层Directory Layer创建唯一路径的子空间来隔离数据。集成测试可能并行执行。应当尽量让测试具备并行安全能力使用唯一 key 范围因为合理的假设是单个服务器会被多个测试共享且可能被并发访问。这与单测不同单测完全独立无需考虑共享状态。这两条约束意味着写集成测试时优先使用 Subspace 或 DirectoryLayer 来划定专属数据区域并在测试结束后清理参考 DirectoryTest.java 中创建目录后finally块里dir.remove的清理模式。七、常见问题与排查建议现象原因与对策新增测试后ctest里看不到tests.cmake修改后未重新执行cmake配置与构建或路径未以src/开头、文件不在src/junit/src/integration目录集成测试被跳过设置了系统属性run.integration.testsfalseRequiresDatabase的兜底开关或当前没有可用集群集成测试在连接阶段快速失败集群未启动或仍在引导RequiresDatabase会在 10 次重试共约 5 秒量级后 fail-fastMulti-Client 测试被 ctest 超时杀死java-multi-integration的 CTest 超时固定为 60 秒见 AddFdbTest.cmake请压缩用例时长只想跑单元测试却混入了原生测试从${BUILD_DIR}顶层改用ctest . -R java-unit精确过滤使用 sanitizer 构建CMake 会直接拒绝运行 Java 测试并给出警告Cannot run java tests with sanitizer builds见 CMakeLists.txt结语FoundationDB Java 绑定的测试体系以目录约定 CMake 登记 ctest 调度三件事为核心目录约定决定了测试的类别src/junit单测、src/integration集成与多客户端测试tests.cmake中的JAVA_JUNIT_TESTS、JAVA_INTEGRATION_TESTS及配套资源变量是构建系统发现测试的唯一入口而 ctest 的-R/-E正则筛选则让开发者可以按需运行任意子集。理解这三层机制后无论是为 Tuple 层补充单元测试还是为目录层、范围查询等能力贡献集成测试或是编写跨集群的 Multi-Client 用例都能做到写好即注册、注册即运行并与 FoundationDB 现有的 CI 与 Joshua 测试体系无缝衔接。【免费下载链接】foundationdbFoundationDB - the open source, distributed, transactional key-value store项目地址: https://gitcode.com/gh_mirrors/fo/foundationdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考