test(coverage): close Theme 8 — 13 test-coverage findings, +35 tests
13 well-bounded test-coverage gaps closed across 11 test projects.
Net +35 regression tests; no production code changes except the
SiteEventLogger src reference unchanged (W3 redacted only test code).
Test additions:
- CLI-022: CommandTreeTests pinned-count assertion bumped 14→16 and
3 InlineData rows added for the audit + bundle command groups.
- Commons-020: new TransportRecordsTests covers BundleManifest /
ExportSelection / ImportPreview / ImportResolution / ImportResult —
ctor + System.Text.Json round-trip + record-equality (14 tests).
- CD-024: SPLIT-RANGE failure-continuation now under
EnsureLookahead_SecondSplitThrows_LoopAborts_FirstBoundaryStillCommitted
(Skippable MS-SQL fixture); production-shape rowversion delete
asserted by DeleteDeploymentRecord_CurrentRowVersion_StubAttachPath_DeleteSucceeds.
- CentralUI-033: new QueryStringDrillInTests with 4 bUnit cases for
Transport + SiteCalls drill-in / query-string handling.
- DM-024: probe actors (ReconcileProbeActor, SerializationProbeActor,
ArtifactProbeActor) refactored from static fields to per-test instances
(Interlocked on counter) — all 31 callers updated; no production
changes required.
- HM-022: real-time PeriodicTimer test flake fixed by replacing
fixed-budget Task.Delay with a RunLoopUntil poll-until-condition
helper (5s/25ms). Production loop untouched.
- InboundAPI-023: new EndpointExtensionsTests covers the
POST /api/{methodName} composition wiring via TestServer (7 cases:
happy path, missing key 401, unknown method 403, invalid JSON 400,
missing param 400, script-throws 500 sanitised, AuditActorItemKey
stash invariant).
- MgmtSvc-021: 6 new ManagementActorTests cover the Transport bundle
handlers (role gate for Export/Preview/Import, unknown-name
ManagementCommandException, blocker-rejection, dedupe last-write-wins).
- SCA-006: SiteCallQueryRequest_StuckOnly_CursorAtNonStuckBoundary_SkipsToNextStuckRow
pins the missing boundary case.
- SEL-023: stress-test `bool stop` promoted to `volatile bool` for
cross-thread visibility under release/JIT.
Verify-only resolutions:
- NS-024: closed by NS-019 (commit ac96b83 deletion of
NotificationDeliveryService + its test file). No edits needed.
- NotifOutbox-008: FallbackMaxRetries/FallbackRetryDelay are private
forward-compat constants returned only when no SMTP-config row exists
(in which case EmailNotificationDeliveryAdapter returns Permanent,
bypassing the values entirely). Marked Resolved with note.
- Transport-010: Overwrite child-collection sync covered by the T-001/
T-002 tests added in commit e3ca9af; per-IP throttle by
BundleUnlockRateLimiterTests; failed-session retention by
BundleSessionStoreTests; T-009 closed structurally via AsyncLocal.
Marked Resolved by reference.
Build clean; all 11 affected test suites green. README regenerated:
33 open (was 46).
This commit is contained in:
@@ -29,13 +29,53 @@ public class CentralHealthReportLoopTests
|
||||
public SiteHealthState? GetSiteState(string siteId) => null;
|
||||
}
|
||||
|
||||
private static async Task RunLoopBriefly(CentralHealthReportLoop loop, int runForMs)
|
||||
/// <summary>
|
||||
/// HealthMonitoring-022 de-flake: <see cref="CentralHealthReportLoop"/>'s
|
||||
/// internal cadence is a real <see cref="PeriodicTimer"/>, so the loop is
|
||||
/// timing-sensitive. We can't drive a virtual clock (PeriodicTimer doesn't
|
||||
/// consume <see cref="TimeProvider"/>) without refactoring the production
|
||||
/// loop, so we keep wall-clock waits but use a *generous* budget: a 5 s
|
||||
/// outer cancellation cap with a poll-until-condition wait, instead of a
|
||||
/// fixed <see cref="Task.Delay"/> that fails fast on a slow CI runner. The
|
||||
/// loop's <c>ReportInterval</c> is set to 50 ms in each test, so under
|
||||
/// normal conditions the condition is met almost immediately; under heavy
|
||||
/// CI load the poll loop tolerates the slow tick instead of asserting on a
|
||||
/// timed-out empty list.
|
||||
/// </summary>
|
||||
private static async Task RunLoopUntil(
|
||||
CentralHealthReportLoop loop,
|
||||
Func<bool> condition,
|
||||
TimeSpan? maxWait = null)
|
||||
{
|
||||
using var cts = new CancellationTokenSource(TimeSpan.FromMilliseconds(runForMs + 100));
|
||||
var deadline = maxWait ?? TimeSpan.FromSeconds(5);
|
||||
using var cts = new CancellationTokenSource(deadline + TimeSpan.FromSeconds(1));
|
||||
try
|
||||
{
|
||||
await loop.StartAsync(cts.Token);
|
||||
await Task.Delay(runForMs, CancellationToken.None);
|
||||
var sw = System.Diagnostics.Stopwatch.StartNew();
|
||||
while (sw.Elapsed < deadline && !condition())
|
||||
{
|
||||
await Task.Delay(25, CancellationToken.None);
|
||||
}
|
||||
await loop.StopAsync(CancellationToken.None);
|
||||
}
|
||||
catch (OperationCanceledException) { }
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Used by tests that need the loop to run for a bounded period without
|
||||
/// waiting on a specific condition (e.g. asserting <i>no</i> reports were
|
||||
/// produced). The wait is generous (1 s default) — see
|
||||
/// <see cref="RunLoopUntil"/> for the rationale.
|
||||
/// </summary>
|
||||
private static async Task RunLoopBriefly(CentralHealthReportLoop loop, int runForMs)
|
||||
{
|
||||
var totalMs = Math.Max(runForMs, 1000);
|
||||
using var cts = new CancellationTokenSource(TimeSpan.FromMilliseconds(totalMs + 1000));
|
||||
try
|
||||
{
|
||||
await loop.StartAsync(cts.Token);
|
||||
await Task.Delay(totalMs, CancellationToken.None);
|
||||
await loop.StopAsync(CancellationToken.None);
|
||||
}
|
||||
catch (OperationCanceledException) { }
|
||||
@@ -56,7 +96,9 @@ public class CentralHealthReportLoopTests
|
||||
collector, aggregator, clusterNodes, options,
|
||||
NullLogger<CentralHealthReportLoop>.Instance);
|
||||
|
||||
await RunLoopBriefly(loop, 250);
|
||||
// HealthMonitoring-022: wait up to 5 s for at least one report to fire
|
||||
// rather than fixed-budget Task.Delay; tolerates slow CI runners.
|
||||
await RunLoopUntil(loop, () => aggregator.Processed.Count >= 1);
|
||||
|
||||
Assert.NotEmpty(aggregator.Processed);
|
||||
Assert.All(aggregator.Processed,
|
||||
@@ -98,7 +140,10 @@ public class CentralHealthReportLoopTests
|
||||
collector, aggregator, clusterNodes, options,
|
||||
NullLogger<CentralHealthReportLoop>.Instance);
|
||||
|
||||
await RunLoopBriefly(loop, 300);
|
||||
// HealthMonitoring-022: wait up to 5 s for at least 2 reports rather
|
||||
// than a fixed 300 ms window that could miss the second tick on a
|
||||
// slow CI runner; the assertion below proves the sequence is monotonic.
|
||||
await RunLoopUntil(loop, () => aggregator.Processed.Count >= 2);
|
||||
|
||||
Assert.True(aggregator.Processed.Count >= 2,
|
||||
$"Expected at least 2 reports, got {aggregator.Processed.Count}");
|
||||
@@ -170,7 +215,10 @@ public class CentralHealthReportLoopTests
|
||||
collector, aggregator, clusterNodes, options,
|
||||
NullLogger<CentralHealthReportLoop>.Instance);
|
||||
|
||||
await RunLoopBriefly(loop, 450);
|
||||
// HealthMonitoring-022: the first ProcessReport call throws (counters
|
||||
// get restored), the second succeeds. Wait up to 5 s for that second
|
||||
// (successful) call rather than a fixed 450 ms budget.
|
||||
await RunLoopUntil(loop, () => aggregator.Processed.Count >= 1);
|
||||
|
||||
// First call threw, later succeeded — the first successful report
|
||||
// must carry the previously-failed interval's accumulated counts.
|
||||
|
||||
Reference in New Issue
Block a user