Skip to content

v0.9.0

Latest

Choose a tag to compare

@github-actions github-actions released this 12 Jun 19:41
· 165 commits to main since this release
v0.9.0
d22c39f

[0.9.0] - 2026-06-12: observe timer fires

Minor release. Adds fire observation to ObservableTimeProvider: a count of how many times timer callbacks ran, next to the existing leak and pending-due assertions. Purely additive. Also corrects stale guidance in the docs.

Added

  • Assert.That(time).HasTimerFiredCount(int expected), HasNoTimerFired(), and HasTimerFiredAtLeast(int count) assert how many times timer callbacks fired across every timer the provider created. ObservableTimeProvider now wraps each timer callback to count its fires. The count is cumulative and is not reset on disposal. With a FakeTimeProvider, a fire is counted each time test code advances fake time past a due or period boundary, which keeps the count deterministic. ObservableTimeProvider.TimerFireCount (cumulative) and ActiveTimerInfo.TimesFired (per timer) expose the same data on the framework-agnostic core.
  • ObservableTimeProvider.CreateTimer now validates that the callback is non-null up front (ArgumentNullException), matching the rest of the surface, instead of deferring to the inner provider.

Fixed

  • Once a periodic timer fires, NextTimerDueTime (and the HasNextTimerDueApproximately / HasPendingTimerDueWithin assertions) now report the timer's period, since that is when the next callback is due. A fired one-shot timer is disabled and drops out of the pending-due calculation. Previously the due time stayed frozen at its creation value until an explicit Change.
  • Corrected stale documentation that claimed the package "deliberately does not ship its own polling assertion": it has shipped HasNoActiveTimersEventually and its count-targeted siblings since 0.7.0/0.8.0. The README and the ActiveTimerAssertions XML docs now point to those overloads for the asynchronous disposal race, reserving generic Eventually for arbitrary conditions.

Changed

  • Bumped PackageValidationBaselineVersion from 0.7.0 to 0.8.1 on both packages so ApiCompat strict-mode validates 0.9.0 against the most recently published baseline. The new members are recorded as additive differences in CompatibilitySuppressions.xml.