provider-integration-tddlisted

# provider-integration-tdd Provider integrations fail in ways unit tests of your own logic never surface: the same event arrives twice, out of order, forged, or three days late. ## The four hazard classes Every provider integration must have tests for whichever of these apply: ### 1. Queues and delivery semantics - **At-least-once is the default.** Assume duplicates. Test that processing the same message twice produces one effect. - **Order is not guaranteed.** Test out-of-order arrival explicitly (e.g. `updated` before `created`). - **Partial failure.** What happens when step 2 of 3 throws? Test that you don't leave a half-applied state. - **Poison messages.** A permanently-failing message must not block the queue forever. Test the dead-letter path. ### 2. Signed webhooks - **Verify the signature before parsing the body.** Test that an invalid signature is rejected *and* that nothing was written. - **Test a forged payload with a valid-looking shape.** Signature checks that are accidentally skipped in one branch are common. - **Timestamp/replay window.** Test that an old-but-correctly-signed payload is rejected. - **Raw body handling.** Frameworks that re-serialize JSON break HMAC verification. Test against the raw bytes. - **Never log the signing secret or the full payload** if it carries PII. ### 3. Idempotent lifecycle - Every state-changing operation needs an **idempotency key** and a test that replaying it is a no-op. - Test the **full lifecycle path**: created