Cover more than the happy path
Include an opted-out favourable result, an unknown result, a duplicate input, a missing output, a reordered output and an unfamiliar status. Each case should have an expected internal action and a reason. Use no real addresses or private records.
Observe rather than assert
Record what your local mapping actually does. A checklist with prefilled pass marks teaches nothing. If a case fails, fix the smallest transformation and rerun the affected cases. Keep the test fixture separate from any production file.
What passing means
Passing these cases supports confidence in your own handling logic. It does not establish vendor accuracy, legal permission, inbox placement or successful live processing. Keep those evidence categories separate in the final acceptance record so the test cannot be misrepresented later.
Put it into practice
Make an expected-versus-observed table for six fictional records. The opted-out favourable record must remain excluded. The unknown record must remain visibly uncertain. The duplicate input must follow the documented mapping without merging independent business states. The missing output must appear in an exception count. The reordered output must still match by the chosen key. The unfamiliar status must trigger review instead of a favourable default. Run these cases through your actual local transformation and write the observed result, including failures. After a repair, rerun the affected cases and retain the version used. Avoid turning the fixture into a live address test: synthetic identifiers are enough to assess mapping behaviour. Passing the table establishes a bounded property of your handling logic only. It does not certify merchant accuracy, data-sharing authority, platform configuration or the outcome of any production import. Keep a failed fixture alongside the repaired version so future mapping changes can be checked against the same concrete regression.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- Bouncer API introduction — Merchant documentation · docs.usebouncer.com · Merchant-controlled · checked 2026-09-27
- Mailchimp audience requirements — Merchant documentation · mailchimp.com · Merchant-controlled · checked 2026-09-27