test(events): integration tests for EventDeployService

[renemadsen]

Summary

Adds NUnit integration tests covering the inline-deploy invariants of EventDeployService (added in PR #813). Catches regressions before they reach master.

Tests added (5)

• EnsureDeployedAsync_NoRotationsInWindow_DoesNothing — empty calendar result, no Compliance writes, SDK core never reached.
• EnsureDeployedAsync_RotationInPast_SkippedNotDeployed — yesterday-dated rotation filtered before the deploy path.
• EnsureDeployedAsync_RotationIsFromCompliance_SkippedNotDeployed — IsFromCompliance=true rotation filtered by the candidate .Where.
• EnsureDeployedAsync_ComplianceAlreadyExists_SkipsRotation — seeds a Compliance for (planningId, deadline.Date), asserts the idempotence guard prevents a duplicate. Uses a custom TestLogger to also pin that the post-guard not-found warning paths are NOT taken — without this, a broken guard would silently produce the same Compliance count via the AreaRulePlanning == null fallthrough.
• EnsureDeployedAsync_CancellationRequested_HonoursToken — pre-cancelled token, asserts OperationCanceledException is thrown and no Compliance rows are written.

Tests deferred (with justifications in code)

• Planning-state immutability — requires a full Planning + PlanningNameTranslation + AreaRulePlanning + AreaRule + Area + Property graph + a real CaseCreate against a real eForm template. Invariant is structurally enforced by the source (no writes to LastExecutedTime/DoneInPeriod/NextExecutionTime/PushMessageSent anywhere) and was pinned by the pre-push code-reviewer on PR feat(events): eager-deploy future events inline in ListEvents #813.
• Per-rotation failure isolation — eFormCore.Core is a concrete class with no interface, so we can't make CaseCreate throw selectively. Follow-up: extract an ICoreFacade or similar.
• Happy-path end-to-end — same setup blocker as Planning-state.

Pre-push gate

• Code-reviewer found two findings, both fixed in 3814d58d:
  • Test Bug fixes #4 tautological (Compliance count == 1 in both "guard fired" AND "guard missed → AreaRulePlanning null fallthrough" branches) — now uses TestLogger to assert the fallthrough paths are NOT taken.
  • Test Fixes #7 cancellation try/catch too permissive — now uses Assert.ThrowsAsync<OperationCanceledException>.
• Code-simplifier found duplication — applied in this PR's final commit.

CI

These tests run as part of the existing test-dotnet job in .github/workflows/dotnet-core-master.yml, which spins up MariaDB via Testcontainers.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a new NUnit integration test fixture, EventDeployServiceTest, that pins five inline-deploy invariants of EventDeployService (introduced in PR #813). The fixture mocks IBackendConfigurationCalendarService and IEFormCoreService to drive the no-op fast paths (no rotations, past rotation, IsFromCompliance=true), seeds a real Compliance row to verify the idempotence guard via a captured-log TestLogger, and asserts that a pre-cancelled CancellationToken propagates as OperationCanceledException with no Compliance writes. Three additional cases (planning-state immutability, per-rotation failure isolation, happy-path E2E) are intentionally deferred with in-file rationale.

Changes:

• New EventDeployServiceTest fixture with 5 active tests + 3 documented skips
• Helpers MakeMocks / MakeService / MakeRotation to reduce per-test boilerplate
• Internal TestLogger<T> capture-only ILogger to support log-based guard assertions

Comments suppressed due to low confidence (2)

eFormAPI/Plugins/BackendConfiguration.Pn/BackendConfiguration.Pn.Integration.Test/EventDeployServiceTest.cs:336

• Test 7's docstring states the EF query at EventDeployService.cs:145 is "GUARANTEED to throw OperationCanceledException". This is misleading: even if EF Core were to ignore the cancellation token at that query, the explicit cancellationToken.ThrowIfCancellationRequested() inside the foreach loop (currently EventDeployService.cs:170) will also throw on the first candidate iteration. The test would still pass via that path, so the comment overstates which line is actually pinning the invariant — and a future regression that drops the token at line 145 (but keeps it at line 170) would not be caught by this test.

        // Act + Assert — the future-day rotation passes the candidate
        // filter, so the pipeline reaches the SDK Sites EF query at
        // EventDeployService.cs:145 which is passed the cancelled token
        // and is GUARANTEED to throw OperationCanceledException (or its
        // TaskCanceledException subclass). A previous swallowing try/catch
        // would have masked a regression that accidentally drops the token
        // (e.g. passes CancellationToken.None to the EF call).
        Assert.ThrowsAsync<OperationCanceledException>(
            () => service.EnsureDeployedAsync(
                PropertyId, BoardIds, "2026-05-14", "2026-05-20", SdkSiteId, cts.Token));

eFormAPI/Plugins/BackendConfiguration.Pn/BackendConfiguration.Pn.Integration.Test/EventDeployServiceTest.cs:336

• Assert.ThrowsAsync runs the supplied async lambda synchronously (via blocking on the returned task) and is not awaited here. Inside an async Task test, the conventional pattern is await Assert.ThrowsAsync<OperationCanceledException>(...) so the exception is observed on the test's async context; the current call works in NUnit but is inconsistent with the rest of the test method (which uses await for every other awaitable) and may also surface analyzer warnings (CA2007 / unawaited task). Adding await keeps the style uniform and avoids any surprise if NUnit ever changes how ThrowsAsync schedules the lambda.

        Assert.ThrowsAsync<OperationCanceledException>(
            () => service.EnsureDeployedAsync(
                PropertyId, BoardIds, "2026-05-14", "2026-05-20", SdkSiteId, cts.Token));