[jayzhan211]

Which issue does this PR close?

• None. Follow-up to the review of ci: stop re-running the workspace test suite in the extended tests job #26649.

Rationale for this change

After #26649, the extended CI step picks its tests with name filters (fuzz_cases::, memory_limit_validation::, spill_pool_scenario_fuzz). If a test behind the extended_tests feature lives somewhere the filters do not match, or a filtered test is renamed, the filter matches nothing, the step still passes, and the test silently stops running in CI.

What changes are included in this PR?

• The tests behind extended_tests now live in one test target, extended_tests, which requires the feature as a whole (required-features = ["extended_tests"] in Cargo.toml). It replaces the fuzz target and holds:

  • fuzz_cases (unchanged contents and test paths).
  • memory_limit_validation, which moves out of core_integration.

  The three #[cfg(feature = "extended_tests")] lines in the source are gone.

• The extended step is now cargo test -p datafusion --test extended_tests --features ..., with no filters. A new test in the target runs without touching the step, and renaming the target makes cargo fail.

• The spill pool fuzzer (1000 iterations) moves to its own step, spill-pool-fuzz, run as a second step of the same job. It cannot share the extended step, because a test filter applies to every test binary in the run. It still selects its test by path.

• Two xtask tests guard what cargo cannot check. xtask is a workspace member, so they run on every PR:

  • spill_pool_fuzz_test_exists fails if the path the spill-pool-fuzz step uses no longer names a test.
  • extended_tests_feature_only_gates_whole_targets fails if any source file gates code on extended_tests with a cfg, since such a test would never run in CI.

• The memory validation runner re-runs each test in a child process by its path. It now also fails if that path selects no test, which would otherwise pass. Moving the tests changes those paths, so this checks the move too.

What is the testing strategy for this PR?

• cargo xtask ci step test extended runs the same tests as before: 134 fuzz tests, and 21 plus 1 already ignored memory validation tests.
• cargo xtask ci step test spill-pool-fuzz runs exactly 1 test.
• cargo test -p datafusion --test extended_tests without the feature fails with "requires the features: extended_tests", and --tests without the feature skips the target, so the workspace step no longer builds it.
• The two new xtask tests fail when the spill pool fuzzer is renamed, when its file is moved, and when a #[cfg(feature = "extended_tests")] is added to core_integration.rs. The memory validation runner fails when its test path prefix is wrong.
• The spill-pool-fuzz step only compiles the datafusion-physical-plan unit test binary, which the extended step also built before this PR.

Fuzz and memory validation tests now run in one process. Each memory validation test measures the RSS of its own child process, so the fuzz tests running next to it do not change what it measures.

Are there any user-facing changes?

No.

[alamb]

Thank you @jayzhan211

[alamb]

❤️

[alamb]

Can we make a single new binary (extended_tests) rather than two new distinct ones -- each binary is several hundred MB

Could be done as a follow on PR

[jayzhan211]

Thanks @alamb !