Create per-library unit test targets#13253
Conversation
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
tclinkenbeard-oai
left a comment
There was a problem hiding this comment.
Generated by Codex.
What is it trying to do?
This PR adds standalone unit-test executables for fdbclient and for selected fdbserver library subdirectories. The targets reuse the flow/fdbrpc UnitTestRunner pattern: link the primary static library with WHOLE_ARCHIVE, filter registered TEST_CASEs by source path component, and keep the targets out of the default build with EXCLUDE_FROM_ALL.
Is it correct?
From code inspection, the approach looks consistent with the existing flow_test and fdbrpc_test targets. The new fdbclient_test removes its main file from FDBCLIENT_SRCS, links fdbclient with whole-archive, and uses the fdbclient suite filter. The add_fdbserver_unit_test helper mirrors the existing fdbserver link-test helper and passes a quoted source-subdirectory suite name into FDBServerUnitTestMain.cpp.
I did not see serialization, protocol-version, persistence-format, async lifetime, or hot-path behavior changes in this PR. Public inline review comments are empty. I did not run build or test validation. The visible FoundationDB CI checks were still pending when I reviewed this, so I would still wait for them before merging.
Are there bugs?
I did not find any correctness bugs in the changed code.
Are there omissions?
The main omission is that this does not create a target for fdbserver/workloads, even though that directory has TEST_CASEs. The PR history shows that target was added and then removed, so this looks intentional rather than accidental, and I do not think it blocks this PR. It may be worth mentioning in the PR description if workloads are excluded because they need heavier simulation/tester dependencies.
Are there better ways of doing things?
No blocking alternatives. Keeping the fdbserver helper next to add_fdbserver_link_test is a reasonable way to avoid repeating the whole-archive/link-dependency pattern across subdirectories.
Should this CL be LGTMd?
Yes, LGTM from code inspection, assuming the pending CI checks pass. The remaining risk is build/link coverage across platform-specific configurations, which CI is the right validation for here.
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
This PR builds on #13207 to create unit test targets for
fdbclientandfdbserversub-components.fdbclient_testuses the same pattern asfdbrpc_test, and a CMakeadd_fdbserver_unit_testfunction is used to add unit test targets forfdbserversub-components. Validated by running individual unit test targets.