Release v16.7.0

Summary

ReactorScenario<T> now resolves reactor handler-method dependencies the way the production reactor pipeline does, and the in-process scenario helpers gain matching ergonomics — register dependencies through a Services collection, seed read models directly, and assert the side effects a reactor returns — so testing reactors and read models no longer requires hand-building a service provider or mocking the event store.

Added

• ReactorScenario<T>.Services collection (with logging registered by default) and an Action<IServiceCollection> constructor for registering a reactor's dependencies.
• Given.ForEventSourceId(id).ReadModel(...) to seed read-model handler-method parameters in a reactor scenario.
• ReactorScenario<T>.ShouldHaveProduced<T>() / ShouldNotHaveProduced<T>() and a Produced list to assert the events and commands a reactor returns as side effects, with no mocked event store.
• ReadModelScenario<T>.Services collection for registering reducer and projection dependencies without supplying a full IServiceProvider.
• CannotActivateReactorForScenario, thrown with the name of the dependency that could not be resolved when a reactor cannot be constructed.

Changed

• A ReactorScenario<T> created without an explicit IServiceProvider now builds one from Services (standard dependency injection with logging registered) instead of using DefaultServiceProvider. A reactor that relied on DefaultServiceProvider constructing an unregistered concrete dependency must now register it.

Fixed

• ReactorScenario<T> now resolves reactor handler-method parameters — injected services and materialized read models — instead of failing to resolve them.