Integrate single header file CppUnitTestFramework for unittests

[howard0su]

Normalize the unittests with the new framework. avoid too many test binaries.

[cubic-dev-ai]

5 issues found across 29 files

Not reviewed (too large): server/test/test_server_unit.cpp (~783 lines) - if these are generated or fixture files, add them to ignored paths to exclude them from future reviews.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="server/test/test_drafter_warm_path_regression.cpp">

<violation number="1" location="server/test/test_drafter_warm_path_regression.cpp:13">
P2: Assert failures within the helper functions won't produce any diagnostic output — no captured message, no file/line info. The runner detects a failure (via caught exception) but can't surface the failing expression or location because TEST_ASSERT bypasses HandleAssert which logs those details. Use the framework's REQUIRE_TRUE(cond) or CHECK_TRUE(cond) macros instead of a custom reimplementation, or route through HandleAssert so failures include the location and expression.</violation>
</file>

<file name="server/test/CppUnitTestFramework.hpp">

<violation number="1" location="server/test/CppUnitTestFramework.hpp:563">
P2: `Close(double, double, double)` safe_div overflow path returns `float::max()` (~3.4e38) instead of `double::max()` (~1.8e308). The overflow guard checks against `double::max()` on line 601 but the return value on this line uses `float::max()`. For double inputs near `DBL_MAX`, the clamped sentinel will be ~53 orders of magnitude too small, which can cause `Close()` to incorrectly report values as within tolerance when one of the operands is extremely large.</violation>
</file>

<file name="server/test/test_kvflash_placement.cpp">

<violation number="1" location="server/test/test_kvflash_placement.cpp:22">
P1: `expect()` now discards the descriptive `msg` string and passes `#cond` (stringified parameter name) to `IsTrue`, so every assertion failure from `expect()` will display `IsTrue(cond)` — completely uninformative. The old code printed the human-readable message (e.g. "C1: no-kvflash reserves full ctx") to stderr on failure; the migration to the framework lost that diagnostic information entirely.

Fix: remove the TEST_ASSERT indirection for `expect()` and call `Assert::IsTrue` directly with `msg` as the description parameter.</violation>
</file>

<file name="server/test/test_cuda_pool_shutdown.cpp">

<violation number="1" location="server/test/test_cuda_pool_shutdown.cpp:15">
P2: Custom TEST_ASSERT macro throws directly without calling CommonFixture::HandleAssert, so assertion failures bypass the framework logger. The ConsoleLogger::AssertFailed method is never called, meaning failure diagnostics — file, line number, and expression text — are not recorded or output by the logger. The exception is caught by TestRegistry::Run and the test is marked as failed, but the failure message is invisible in verbose output and adapter mode.</violation>
</file>

<file name="server/CMakeLists.txt">

<violation number="1" location="server/CMakeLists.txt:983">
P2: The RED regression binary is compiled with the GREEN formula, so it can no longer document or detect Bug #42. Apply the definition only to `test_server_unit` rather than setting it on the shared source file.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: expect() now discards the descriptive msg string and passes #cond (stringified parameter name) to IsTrue, so every assertion failure from expect() will display IsTrue(cond) — completely uninformative. The old code printed the human-readable message (e.g. "C1: no-kvflash reserves full ctx") to stderr on failure; the migration to the framework lost that diagnostic information entirely.

Fix: remove the TEST_ASSERT indirection for expect() and call Assert::IsTrue directly with msg as the description parameter.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At server/test/test_kvflash_placement.cpp, line 22:

<comment>`expect()` now discards the descriptive `msg` string and passes `#cond` (stringified parameter name) to `IsTrue`, so every assertion failure from `expect()` will display `IsTrue(cond)` — completely uninformative. The old code printed the human-readable message (e.g. "C1: no-kvflash reserves full ctx") to stderr on failure; the migration to the framework lost that diagnostic information entirely.

Fix: remove the TEST_ASSERT indirection for `expect()` and call `Assert::IsTrue` directly with `msg` as the description parameter.</comment>

<file context>
@@ -5,21 +5,27 @@
+        throw *_cpputf_exception; \
+    } \
+} while (0)
+static void expect(bool cond, const char * msg) { (void) msg; TEST_ASSERT(cond); }
+
+namespace {
</file context>

Suggested change

	static void expect(bool cond, const char * msg) { (void) msg; TEST_ASSERT(cond); }
	static void expect(bool cond, const char * msg) {
	auto _cpputf_exception = CppUnitTestFramework::Assert::IsTrue(static_cast<bool>(cond), msg);
	if (_cpputf_exception) {
	throw *_cpputf_exception;
	}
	}

[cubic-dev-ai]

P2: Assert failures within the helper functions won't produce any diagnostic output — no captured message, no file/line info. The runner detects a failure (via caught exception) but can't surface the failing expression or location because TEST_ASSERT bypasses HandleAssert which logs those details. Use the framework's REQUIRE_TRUE(cond) or CHECK_TRUE(cond) macros instead of a custom reimplementation, or route through HandleAssert so failures include the location and expression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At server/test/test_drafter_warm_path_regression.cpp, line 13:

<comment>Assert failures within the helper functions won't produce any diagnostic output — no captured message, no file/line info. The runner detects a failure (via caught exception) but can't surface the failing expression or location because TEST_ASSERT bypasses HandleAssert which logs those details. Use the framework's REQUIRE_TRUE(cond) or CHECK_TRUE(cond) macros instead of a custom reimplementation, or route through HandleAssert so failures include the location and expression.</comment>

<file context>
@@ -9,6 +10,19 @@
 using dflash::common::ScoreRange;
 using dflash::common::compute_score_range;
 
+#define TEST_ASSERT(cond) do { \
+    auto _cpputf_exception = CppUnitTestFramework::Assert::IsTrue(static_cast<bool>(cond), #cond); \
+    if (_cpputf_exception) { \
</file context>

[cubic-dev-ai]

P2: Close(double, double, double) safe_div overflow path returns float::max() (~3.4e38) instead of double::max() (~1.8e308). The overflow guard checks against double::max() on line 601 but the return value on this line uses float::max(). For double inputs near DBL_MAX, the clamped sentinel will be ~53 orders of magnitude too small, which can cause Close() to incorrectly report values as within tolerance when one of the operands is extremely large.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At server/test/CppUnitTestFramework.hpp, line 563:

<comment>`Close(double, double, double)` safe_div overflow path returns `float::max()` (~3.4e38) instead of `double::max()` (~1.8e308). The overflow guard checks against `double::max()` on line 601 but the return value on this line uses `float::max()`. For double inputs near `DBL_MAX`, the clamped sentinel will be ~53 orders of magnitude too small, which can cause `Close()` to incorrectly report values as within tolerance when one of the operands is extremely large.</comment>

<file context>
@@ -0,0 +1,846 @@
+            auto safe_div = [](float a, float b) -> float {
+                // Avoid overflow.
+                if ((b < 1.0f) && (a > b*std::numeric_limits<float>::max())) {
+                    return std::numeric_limits<float>::max();
+                }
+
</file context>

Suggested change

	return std::numeric_limits<float>::max();
	return std::numeric_limits<double>::max();

[cubic-dev-ai]

P2: Custom TEST_ASSERT macro throws directly without calling CommonFixture::HandleAssert, so assertion failures bypass the framework logger. The ConsoleLogger::AssertFailed method is never called, meaning failure diagnostics — file, line number, and expression text — are not recorded or output by the logger. The exception is caught by TestRegistry::Run and the test is marked as failed, but the failure message is invisible in verbose output and adapter mode.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At server/test/test_cuda_pool_shutdown.cpp, line 15:

<comment>Custom TEST_ASSERT macro throws directly without calling CommonFixture::HandleAssert, so assertion failures bypass the framework logger. The ConsoleLogger::AssertFailed method is never called, meaning failure diagnostics — file, line number, and expression text — are not recorded or output by the logger. The exception is caught by TestRegistry::Run and the test is marked as failed, but the failure message is invisible in verbose output and adapter mode.</comment>

<file context>
@@ -7,7 +8,18 @@
+struct CudaPoolShutdownFixture {};
+}
+
+#define TEST_ASSERT(cond) do { \
+    auto _cpputf_exception = CppUnitTestFramework::Assert::IsTrue(static_cast<bool>(cond), #cond); \
+    if (_cpputf_exception) { \
</file context>

[cubic-dev-ai]

P2: The RED regression binary is compiled with the GREEN formula, so it can no longer document or detect Bug #42. Apply the definition only to test_server_unit rather than setting it on the shared source file.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At server/CMakeLists.txt, line 983:

<comment>The RED regression binary is compiled with the GREEN formula, so it can no longer document or detect Bug #42. Apply the definition only to `test_server_unit` rather than setting it on the shared source file.</comment>

<file context>
@@ -1082,15 +943,48 @@ if(DFLASH27B_TESTS)
-        target_include_directories(test_server_unit PRIVATE ${DFLASH27B_SRC_INCLUDE_DIRS})
+            src/server/prompt_normalize.cpp
+            src/qwen3/anchor_scan.cpp)
+        set_source_files_properties(test/test_drafter_tail_capture_guard.cpp
+            PROPERTIES COMPILE_DEFINITIONS TAIL_GUARD_USE_NEW_FORMULA)
+        target_include_directories(test_server_unit PRIVATE
</file context>

[cubic-dev-ai]

All reported issues were addressed across 1 file (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="server/CMakeLists.txt">

<violation number="1" location="server/CMakeLists.txt:1017">
P2: Cross-compiling `test_server_unit` now fails at link time's post-build step because the target binary is unconditionally executed on the build machine. Discovery could be skipped or routed through a configured `CMAKE_CROSSCOMPILING_EMULATOR`, with the CTest registration handled accordingly for cross builds.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Cross-compiling test_server_unit now fails at link time's post-build step because the target binary is unconditionally executed on the build machine. Discovery could be skipped or routed through a configured CMAKE_CROSSCOMPILING_EMULATOR, with the CTest registration handled accordingly for cross builds.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At server/CMakeLists.txt, line 1017:

<comment>Cross-compiling `test_server_unit` now fails at link time's post-build step because the target binary is unconditionally executed on the build machine. Discovery could be skipped or routed through a configured `CMAKE_CROSSCOMPILING_EMULATOR`, with the CTest registration handled accordingly for cross builds.</comment>

<file context>
@@ -1007,50 +1006,25 @@ if(DFLASH27B_TESTS)
+            CONTENT "include([==[${_server_unit_ctest_generated}]==] OPTIONAL)\n")
+        set_property(DIRECTORY APPEND PROPERTY TEST_INCLUDE_FILES
+            "${_server_unit_ctest_include}")
+        add_custom_command(TARGET test_server_unit POST_BUILD
+            COMMAND ${CMAKE_COMMAND}
+                -DTEST_EXECUTABLE=$<TARGET_FILE:test_server_unit>
</file context>