Repository navigation
Release v19.40.0
Summary
The in-process testing scenarios (EventScenario, ReadModelScenario, ReactorScenario and EventStoreForTesting) now run on Chronicle's production in-memory storage instead of hand-written test doubles, so they behave like a real event store in more of the places your specifications depend on.
Added
EventScenarioconstructors that take an explicit event sequence, event store and namespace, and still discover the constraints your application declares:new EventScenario(sequenceId, eventStore, @namespace)andnew EventScenario(defaults, sequenceId, eventStore, @namespace). Passing an explicitnullconstraint provider to the existing constructor still means no constraints (#4520)ReadModelScenario,ReactorScenarioandEventStoreForTestingimplementIDisposable, likeEventScenario. Dispose a scenario to release its in-memory event store, for example from your specification'sDestroy()
Changed
- Testing scenarios share one in-memory event store per scenario. The event log and any named event sequence you append to see the same data, and kernel services that used to throw
NotSupportedExceptionin a scenario now answer from that store. For example, the admin password status now reports that no admin password is required (#3434) - An event appended in an older generation is migrated through your registered event type migrations (
EventTypeMigration<TUpgrade, TPrevious>) and stored in every generation, inEventScenarioas well as in the events you seed intoReadModelScenario. Read models and reducers now see the migrated values (part of #3941) EventStoreForTestingenforces closes-stream constraints, asEventScenarioalready did- Concurrent appends to one event sequence in a scenario run one at a time, the way the kernel processes them. Two concurrent appends of the same
[Unique]value can no longer both succeed - An event type or generation your scenario did not discover still fails with
EventSchemaNotDiscovered. A constraint type the kernel does not know now fails explicitly instead of being ignored