 |
VOOZH | about |
|
VOOZH | about |
dotnet add package Stratara.Testing.EntityFrameworkCore --version 3.1.4
NuGet\Install-Package Stratara.Testing.EntityFrameworkCore -Version 3.1.4
<PackageReference Include="Stratara.Testing.EntityFrameworkCore" Version="3.1.4" />
<PackageVersion Include="Stratara.Testing.EntityFrameworkCore" Version="3.1.4" />Directory.Packages.props
<PackageReference Include="Stratara.Testing.EntityFrameworkCore" />Project file
paket add Stratara.Testing.EntityFrameworkCore --version 3.1.4
#r "nuget: Stratara.Testing.EntityFrameworkCore, 3.1.4"
#:package Stratara.Testing.EntityFrameworkCore@3.1.4
#addin nuget:?package=Stratara.Testing.EntityFrameworkCore&version=3.1.4Install as a Cake Addin
#tool nuget:?package=Stratara.Testing.EntityFrameworkCore&version=3.1.4Install as a Cake Tool
Spin up the real Stratara event-sourcing write stack — IEventSource, IAggregationService,
snapshots, and the EF Core write store — against a shared in-memory SQLite database, in one
call. You exercise production code paths (real serialization, real version tracking, real unique
constraints) without Postgres or Docker.
Builds on Stratara.Testing: the cross-cutting
dependencies are wired with its in-memory doubles (InMemoryKeyStore, TestSessionContextProvider).
IEventSource?Because a bespoke fake would drift from production (subject resolution, concurrency detection,
outbox dispatch, snapshots). This package runs the genuine EventSource on SQLite instead, so your
tests verify the real behavior.
await using var host = EventStoreTestHost.Create(s =>
s.AddAggregatesFromAssemblyContaining<Account>());
await host.ExecuteAsync(async events =>
{
await events.CreateAsync<Account>(id, new AccountOpened(id, tenantId, "Ada", 100m));
await events.AppendAsync<Account>(id, new AmountWithdrawn(30m));
await events.SaveChangesAsync();
});
var account = await host.AggregateAsync<Account>(id);
Assert.Equal(70m, account!.Balance);
Assert.Single(host.Outbox.Bundles); // the SaveChanges emitted one bundle
EventStoreTestHost — owns a shared open SQLite connection + a configured service provider;
exposes ExecuteAsync(IEventSource), AggregateAsync<T>(streamId), the preset Session, and the
recording Outbox. IAsyncDisposable.AddStrataraTestingEventStore<TWriteDbContext>(connection, tenantId) — the lower-level DI
extension if you compose the provider yourself.StrataraTestWriteDbContext — a ready-made concrete write context (no subclass boilerplate).RecordingEventBundleOutboxDispatcher — captures emitted bundles for assertions.:memory: and shared across every DbContext the unit of work mints — it
must stay open for the host's lifetime (the host manages this; dispose it when done).AddAggregatesFromAssemblyContaining<T>()) so event payload types
deserialize on rehydration.Stratara.Testing, Stratara.Infrastructure, Stratara.EventSourcing.EntityFrameworkCore,
Stratara.Shared, Stratara.Abstractions, Stratara.ContractsMicrosoft.EntityFrameworkCore.SqliteReference it from test projects only.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 net10.0 is compatible. net10.0-android net10.0-android was computed. net10.0-browser net10.0-browser was computed. net10.0-ios net10.0-ios was computed. net10.0-maccatalyst net10.0-maccatalyst was computed. net10.0-macos net10.0-macos was computed. net10.0-tvos net10.0-tvos was computed. net10.0-windows net10.0-windows was computed. |
This package is not used by any NuGet packages.
This package is not used by any popular GitHub repositories.
### Added
- **Command-workload isolation (heavy-command lane)** — long-running commands can now be routed to a
dedicated worker lane so they cannot starve interactive commands. Mark a command with the new
`Stratara.Abstractions.Mediator.IHeavyCommand` marker and the `ICommandOutboxDispatcher`
automatically publishes it to a separate heavy-command topic (`IMessagingIdentifier.HeavyCommandTopic` /
`HeavyCommandSubscription`, configurable under `Messaging:HeavyCommand`, defaulting to `heavy-command` /
`heavy-command-subscription`). Run a dedicated heavy-command worker with the new
`services.AddHeavyCommandWorker(degreeOfParallelism?)` extension, or the
`builder.AddHeavyCommandWorkerServices(degreeOfParallelism?)` host composite — in the same process as
the interactive worker (two lanes) or in a separately scaled host. Each worker's degree of parallelism
is configurable per lane. `IMessagingIdentifier` gains `HeavyCommandTopic`, `HeavyCommandSubscription`,
and the `GetCommandTopic(Type)` / `GetCommandSubscription(Type)` routing helpers. The interactive lane
(`AddMediatorWorker()`) is unchanged and remains the default; commands not marked heavy keep their
existing routing. If a heavy command is dispatched while no heavy worker is bound, the publish is
rejected and the command is preserved in the outbox until a heavy-command worker comes online — it is
never dropped. Works over both the RabbitMQ and Azure Service Bus message buses (Azure Service Bus
requires the heavy-command topic/subscription to be provisioned, like the existing command topic). New
log-event ID `105_005` (`CommandWorkerLaneStarted`) in `Stratara.Diagnostics`.
- **Observability metrics across the worker pipeline** (`Stratara.Diagnostics`) — the shared
`Stratara.Service` meter now publishes throughput and latency instruments so operators can see how the
event-sourcing pipeline is behaving instead of flying blind on a single counter. New instruments:
`event_source.events.appended` (counter, tagged by `event.type` / `aggregate.type`),
`outbox.published` (counter, tagged by `outbox.kind` = `command` / `event`), `command.duration`
(histogram, ms, tagged by `request.type` / `outcome`), `projection.events.processed` (counter) +
`projection.bundle.duration` (histogram, ms), `saga.events.processed` (counter) +
`saga.bundle.duration` (histogram, ms), and `saga.inflight` (up/down counter). They are recorded by the
event source, command worker, projection worker, saga worker, and outbox worker respectively. Because
projections and sagas are real-time bus subscribers without a persisted checkpoint, these report
**throughput and latency**, not consumer lag. No configuration is required — point any OpenTelemetry
metrics exporter at the `Stratara.Service` meter.
- **Operational health checks for the event store and outbox** (`Stratara.EventSourcing.EntityFrameworkCore`) —
two opt-in readiness checks added to any `IHealthChecksBuilder`: `AddEventStoreHealthCheck()` verifies
the write-side database is reachable, and `AddOutboxHealthCheck(degradedThreshold?, unhealthyThreshold?)`
reports the pending outbox backlog (exposed under the `pending` data key) and escalates to
`Degraded` / `Unhealthy` when the backlog crosses the supplied thresholds. Both are tagged `ready` by
default (so they map to a readiness endpoint, not liveness) and require the Stratara write store to be
registered. The write-store DbContext is now also resolvable as a scoped `IWriteDbContext` service to
support these checks.
- **Polly-backed mediator resilience behavior** (`Stratara.Resilience`) — an opt-in pipeline behavior
wraps the in-process dispatch of a request marked with the new
`Stratara.Abstractions.Resilience.IResilientRequest` in the named Polly pipeline the request selects
(`ResiliencePipelineName`). Register it with the new `AddStrataraResilienceBehavior()` (after
`AddStrataraValidation()` / `AddStrataraTenantIsolation()` so the retry wraps the handler, not the
guards); requests without the marker are unaffected. A new built-in pipeline
`ResilienceNames.ConcurrencyConflict` retries **only** on
`Stratara.Abstractions.Persistence.ConcurrencyConflictException` (5 attempts, short exponential
backoff) so a handler that re-reads and re-applies on an optimistic-concurrency clash succeeds without
bespoke retry loops; it is registered by `AddResiliencePipelines()` alongside the existing message-bus
and dispatcher pipelines. Only mark handlers that are safe to re-run (idempotent or concurrency-guarded).