Speed up Lite.Tests: share one DuckDB fixture per analysis-heavy test class

[erikdarlingdata]

Summary

Share one DuckDB database per test CLASS in the seven analysis-heavy Lite.Tests classes, instead of creating a database and laying down the full schema (36+ collector tables + indexes + archive views + analysis schema, ~80 DDL statements) inside every single test. A new SharedDuckDbFixture (xUnit IClassFixture) builds the schema once per class; each test starts by resetting DATA only - every base table is emptied except the schema_version / analysis_schema_version stamps, so the database keeps reading as current between tests rather than as a blank file needing migration.

Deliberately IClassFixture, NOT a collection fixture: a single shared collection would serialize the seven classes against each other and hand back most of the win. Each class owns its own database file, so xUnit's cross-class parallelism is untouched.

Classes converted (exactly the CI "analysis-heavy" filter):

• AnomalyDetectorTests
• FactCollectorTests
• FactCollectorMiseryTests
• BaselineProviderTests
• InferenceEngineTests
• ScenarioTests
• AnalysisServiceTests

TestDataSeeder is untouched: its per-scenario ClearTestDataAsync() calls are load-bearing (tests like MuteFinding_ExcludesFromNextRun re-seed mid-test and rely on the scoped clear). The fixture's reset list is a runtime information_schema snapshot, not a hand-maintained list - the AG collector tables that landed on dev mid-branch were picked up with zero changes.

Also removes the ~60 per-test InitializeAnalysisSchemaAsync() calls, which were duplicate work even before this change (InitializeAsync() already ends by calling it). Net -187 lines.

Measurements (local, Debug, --no-build)

The win scales with CPU contention, because what the fixture eliminates is 153 redundant schema builds whose cost balloons when cores are scarce:

Conditions	Run	Before	After
Contended box (parallel builds running)	Analysis-heavy filter (153 tests)	233s	175s (-25%)
Idle box, back-to-back pair	Analysis-heavy filter (153 tests)	164s	159s (-3%)
Idle box	Full suite (1479 tests)	233s	(window reloaded; see note)

On an idle desktop the per-test schema build only costs ~0.2-0.3s, so the remaining runtime is genuine per-test analysis work (row-by-row seeding + pipeline queries). The ~1.4s/test measured locally before, and CI's 556s / 153 = ~3.6s/test, are the contended regime - CI's small runner is permanently contended, so the "Run Lite analysis-heavy tests" step is where this change should show its real value. This PR's own CI run is the decisive number. Full-suite after-timings on the idle window were polluted by external load returning mid-measurement (the same binary swung 286s-442s run to run); pass counts, not local wall-clock, are the reliable local signal.

Isolation proof

Sharing a database is exactly what lets one test poison the next, so isolation was proven, not assumed:

• Every test starts from pristine data via ResetData() in the test class constructor (xUnit constructs the class per test and runs a class's tests serially, so the shared DB is never touched concurrently).
• The reset covers ALL base tables - including analysis_findings / analysis_muted, which the seeder's server-scoped clear never touched - so persisted findings and mute rules cannot leak between tests.
• Full suite run twice consecutively, same session: identical results (1479/1479 passed, 0 failed, 0 skipped, both runs). Post-merge with latest dev: 1494/1494.
• One unrelated CredentialProfileTests failure appeared in a separate run - the known load-flaky credential-store family (no DuckDB involvement); passes 13/13 in isolation.
• No test depended on a pristine SCHEMA rather than pristine data: none of the seven creates/drops tables, touches parquet/archive views, or calls ResetDatabaseAsync (verified by reading all seven classes end to end).

Not changed, and why

• .github/workflows/build.yml - deliberately untouched per the fast/heavy split being cheap.
• 28 other Lite.Tests classes also create per-test DuckDB databases, but they live in CI's fast bucket and several must NOT share (MuteRulesSurviveResetTests deletes the DB file via ResetDatabaseAsync; ArchiveViewDedupTests writes parquet and rebuilds views). Follow-up material if the fast bucket ever becomes the bottleneck.

Generated with Claude Code