Appearance
Test your consumer
Two ways to test a consumer, and a good integration uses both:
- Test runs in the portal play the bus's own consumer scenarios into your workspace (duplicates, a late snapshot, unknown types, a newer minor version) and grade the end state your consumer reports. See Test runs.
- Your own tests, below: publish with a producer app of your own and check your consumer's end state, what it stores or shows, not just what it logged. Two of them need a replay or a redrive, which you start yourself under Consumer connections in the portal.
| Test | Do | Your consumer must end with |
|---|---|---|
| T1 Whole story | Publish the hurricane run, snapshots 1 to 7, then a KILLED snapshot | Snapshot 7's content exactly, then the story shown as killed, or gone from live views |
| T2 Replay | Replay your connection from before T1 | The same end state as after T1. Nothing doubled |
| T3 Late older snapshot | Make your handler fail on snapshot 3 until it reaches your dead-letter queue; let 4 to 7 through; fix it and redrive | Snapshot 7 still current. Snapshot 3 dropped, not applied |
| T4 Unknown things | Publish a snapshot with an extension com.othervendor.x, and, if your grants allow, a message type your consumer doesn't know | Handled normally, the unknown parts ignored. No error, nothing in the dead-letter queue |
| T5 Newer minor version | Publish a new story with the same snapshot content, som_version: "1.1.0" and one extra payload field (the same story again would be refused as stale) | Exactly the same end state as the 1.0.0 story |
| T6 Poison message | Make your handler throw for one story | That story's message reaches the dead-letter queue after the connection's attempt limit, other stories keep flowing, and you're alerted |
| T7 Outage | Stop your consumer, publish a story, start it again | Everything arrives, in order |
What each test checks is on Order, duplicates and snapshots.
Checkpoint
- [ ] My consumer acknowledges a message only after handling it, with enough visibility for slow work (
visibilityon the pull API;ChangeMessageVisibilityon the queue). - [ ] Every consumer scenario in a test run passes.
- [ ] It keeps the highest
sequence_numberper story and applies snapshots as whole replacements. - [ ] It's idempotent on
message_id, and ignores unknown types, extensions and fields. - [ ] T1 to T7 end in the expected state, and I'm alerted on my dead-letter queue.