TimeAssertions 0.7.0

• net10.0

  • No dependencies.

View the rendered release notes: https://github.com/JohnVerheij/TimeAssertions.TUnit/releases/tag/v0.7.0

Minor release. Adds real-time "eventually" active-timer assertions for the asynchronous timer-disposal race a synchronous leak check cannot see, plus synchronous positive-count assertions to express a lower bound on the active set.

### Added

- **`Assert.That(provider).HasNoActiveTimersEventually(TimeSpan timeout, TimeSpan? pollingInterval = null, CancellationToken ct = default)`** (TUnit adapter) polls the live `ActiveTimerCount` on the real wall clock until it reaches zero, or the timeout elapses. A `BackgroundService` / `IHostedService` commonly disposes its timer on a continuation that runs after `StopAsync` returns to the caller, so a synchronous `HasNoActiveTimers()` check just after stop can still see the timer; the poll gives that continuation time to run. The condition is checked once before the first delay, so an already-clean provider passes without waiting. On timeout the failure names each surviving timer by its schedule with a grep-friendly `(count=N)` trailer.
- **`Assert.That(provider).HasActiveTimerCountEventually(int count, TimeSpan timeout, TimeSpan? pollingInterval = null, CancellationToken ct = default)`** (TUnit adapter) is the count-targeted sibling: polls until `ActiveTimerCount` equals `count`, for an active set that settles to a steady state on a background continuation. On timeout it renders the expected and actual counts with an `(expected=N, actual=M)` trailer plus the active timers' schedules.
- **`Assert.That(provider).HasActiveTimers()`** (TUnit adapter) passes when at least one timer is active: the positive-presence counterpart of `HasNoActiveTimers()` for the registration half of a leak test, without pinning the exact count. Source-generated via `[GenerateAssertion]`.
- **`Assert.That(provider).HasAtLeastActiveTimerCount(int count)`** (TUnit adapter) passes when the active count is at least `count`, for when a lower bound rather than an exact count is the natural expectation. On a shortfall it renders the required minimum and the actual count with a `(minimum=N, actual=M)` trailer plus the active timers' schedules. Source-generated via `[GenerateAssertion]`.
- **Positional-`CancellationToken` overloads** of `HasNoActiveTimersEventually` and `HasActiveTimerCountEventually` (TUnit adapter) let a token follow the timeout positionally while keeping the default poll interval, so the common case reads as `(timeout, ct)` / `(count, timeout, ct)` instead of the named `ct:` form. They forward to the canonical chain with `pollingInterval: null`; the token parameter has no default, so a bare `(timeout)` call stays unambiguous, matching TUnit's `WaitsFor` convention.
- **`TimeAssertions.TimeRenderingHelpers.FormatActiveTimerSurvivors(...)` and `FormatActiveTimerAtLeastShortfall(...)`** (framework-agnostic core) render the survivor list for the eventually-timeout messages and the at-least shortfall message, ordering survivors deterministically (by due time, then period) so the messages are snapshot-stable.

The poll uses a real `Task.Delay` loop against a wall-clock deadline rather than a fake-time advance: hosted-service timer disposal happens on a real asynchronous continuation, which a fake clock cannot drive. The default poll interval is 10 ms; supply your own via the optional `pollingInterval`. A canceled `CancellationToken` throws `OperationCanceledException` so the test is recorded as canceled rather than failed.