The latest articles on DEV Community by Mira Lund (@mira_lund). https://dev.to/mira_lund https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4215001%2F4170c212-17cb-4cac-a72e-63e4e3f78a4c.jpg https://dev.to/mira_lund en Mira Lund Thu, 29 Oct 2026 10:22:25 +0000 https://dev.to/mira_lund/the-dbt-test-that-would-have-caught-our-duplicate-orders-3oc5 https://dev.to/mira_lund/the-dbt-test-that-would-have-caught-our-duplicate-orders-3oc5 <p>Six weeks of duplicate orders in a revenue dashboard, and the fix was a test we already knew how to write.</p> <p>What happened: our orders source table got a second feed during a migration. Both feeds used the same order id, so joins against order items fanned out and every affected order counted twice. Nobody noticed because the number went up slowly, and up looks like growth.</p> <p>The test that would have caught it on day one is boring: a uniqueness test on order_id in the staging model. Not on the mart, on staging, where the two feeds first meet. We had a uniqueness test on the mart's order_id, and it passed the whole time, because the mart aggregated before it duplicated.</p> <p>Two other rules I now apply:</p> <p>Tests belong at the first place two sources meet, not at the end of the pipeline.</p> <p>If a source gains a feed, the staging model needs a review, not just a backfill.</p> <p>The dashboard was never wrong about what it measured. It was measuring two versions of the same order.</p> dbt data sql