test: Remove timing dependencies from worker tests

[Kampfmoehre]

Follow-up to #1673. Fixes the flaky test that failed on #1667, plus three more with the same defect found while verifying.

Note

The coverage job on this PR will stay red until #1673 is merged — that's the unrelated coveralls timezone crash, not this change.

The flake from CI

AddFailedProgressAsync_ShouldAddFailedProgres let the process function sleep 100 ms, then called AddFailedProgressAsync after StartAsync returned:

sut.SetProcessFunction(async (_j, ct) => { await Task.Delay(100, ct); return null; });
await sut.StartAsync(ct);
await sut.CallAddFailedProgressAsync(7);

StartAsync returns as soon as ExecuteAsync suspends — which is inside that Task.Delay(100). If the test thread isn't scheduled again within 100 ms, HandleJobRunAsync finishes and sets _jobRepository = null (JobWorkerBase.cs:360), so the call throws:

System.InvalidOperationException : Unable to set job items because no job repository is set.

Reproduced deterministically by inserting a 300 ms delay after StartAsync — byte-identical to the CI failure.

The two sibling tests (SetTotalItemsAsync_ShouldSetTotalItems, AddProgressAsync_ShouldAddProgress) had already been converted to a TaskCompletionSource handshake. This one was missed; it now uses the same pattern.

Three more with the same defect

The AddInitialJob tests waited a fixed Task.Delay(10) — "Give some time to add job" — before asserting. They now wait on a new TestWorker.JobRunCompleted, which completes when the worker's first iteration has actually finished.

This also removes a false negative: AddInitialJob_ShouldNotAddInitialJob_IfThereIsAnyInDueRange asserts AddJobAsync was never called, which previously could pass simply because the worker hadn't reached that code yet. Waiting for the iteration to complete makes the assertion meaningful.

I used the PostJobRunHookAsync seam rather than a callback on the AddJobAsync mock: a mock callback can't work for the negative test (you can't wait for a call that must never happen), and one uniform mechanism beats two.

Un-skipped test

SetTotalItemsAsync_ShouldThrowInvalidOperationException_WhenNoCurrentJobIsSet was marked:

Skip = "Find a way to setup state for this without repo being nulled after a run"

It needs _jobRepository != null && _currentJob == null. That window exists: DeleteOldJobs runs after _currentJob is reset but before _jobRepository is nulled. Blocking inside the DeleteJobsAsync mock holds the worker there deterministically.

Verified it isn't passing vacuously — with the wait removed it fails on the other branch:

Expected: ···"to set job items because no current job exists."
Actual:   ···"to set job items because no job repository is set."

Evidence

All soaks on 16 cores with 2× busy-loop load:

	Before	After
AddFailedProgressAsync_ShouldAddFailedProgres	0/15 pass	15/15 pass
AddInitialJob_ShouldAddAnInitialJob_IfConfigured	2/6 pass	—
Whole JobService.Test project	—	20/20 pass

Full solution green 3× (17 + 17 + 19 passed, 0 skipped — was 1 skipped).

No production code changed; TestWorker gains one test-only seam.

🤖 Generated with Claude Code

https://claude.ai/code/session_015BX2NY9ozmWKHsifii1KYP