Behavioral suite · 12 scenarios
Consumer stories with observable outcomes.
Given/When/Then scenarios exercise audited domain flows, nested workflows, lifecycle teardown, routing boundaries, synchronous replies, shared payloads, failures, async side effects, and live membership.
Complete Behavioral inventory
12- given an audited order retry with one-time reservation and persistent projection, when the same order is published twice, then the audit leads both deliveries while reservation happens once
- given an order handler that publishes the next workflow stage, when an order is created, then the nested fulfillment stage completes before outer delivery continues
- given a one-time readiness gate that reenters its own topic, when the outer readiness signal arrives, then the gate is consumed before the nested signal
- given a mounted subscriber that observes application updates, when the subscriber unmounts, then later updates no longer reach it
- given listeners from an authenticated session, when logout resets the event hub and a new session starts, then only the new session observes later activity
- given a bridge that forwards only public topics to another hub, when private and public messages are published, then only public messages cross the boundary
- given a request carrying a reply callback, when a subscriber handles the request, then the caller receives the reply before publish returns
- given a wildcard normalizer and a typed consumer sharing a payload, when the payload is published, then the consumer and caller observe the normalized object
- given a one-time preflight followed by a failing persistent subscriber, when delivery is retried after the failure, then preflight stays consumed and the exact failure keeps reaching the publisher
- given an asynchronous side effect beside a synchronous projection, when the event is published, then publish returns after starting both without awaiting the side effect
- given subscriber membership that changes during a notification, when the current delivery adds one subscriber and removes another, then the added subscriber joins immediately and the removed one is skipped
- given two tenant hubs with the same topic names, when each tenant publishes an update, then each update stays within its originating tenant