solid checklist. i still would not sign off on a total that never said what one row means.
order versus order line sounds pedantic until a join quietly multiplies the sum. nulls and duplicates can all pass while the grain is wrong. naming that grain before uat, then sitting a few rows at that level next to the aggregate, caught more bad sign offs for us than another null scan did.
Agree, and I'd put the grain above all seven. One line at the top of the test plan, "one row = one order line," settles half the arguments before they start. Putting a few rows next to the total is a good habit too. I made a short video on exactly this, one join quietly inflating a sum: youtube.com/watch?v=SG-6rtZeizg
putting the grain first is exactly what i wish more plans opened with.
one line like 'one row = one order line' at the top probably settles more fights than another null scan. what worked for a teammate was forcing that sentence into the PR description before anyone looked at the seven checks. then sitting a few rows at that grain next to the total made the quiet join blowups obvious. i'll check your video on the inflated sum, that failure mode is the one i keep underestimating.
Putting it in the PR description is a smart forcing function, because it's the one place nobody skips. I'm stealing that. The same line works as a UAT entry criterion: no grain sentence, no testing starts. Hope the video is useful, and tell me if the fan-out example looks like the blowups you've seen.
Making the grain sentence a hard entry gate is sharper than leaving it as advice.
We tried the soft version first and people still skipped it under deadline. Once testing could not start without that one line in the PR, the fan-out cases showed up earlier, usually as an order-line total that quietly matched invoice count. Your video's blowup shape is the same one we keep walking into.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
solid checklist. i still would not sign off on a total that never said what one row means.
order versus order line sounds pedantic until a join quietly multiplies the sum. nulls and duplicates can all pass while the grain is wrong. naming that grain before uat, then sitting a few rows at that level next to the aggregate, caught more bad sign offs for us than another null scan did.
Agree, and I'd put the grain above all seven. One line at the top of the test plan, "one row = one order line," settles half the arguments before they start. Putting a few rows next to the total is a good habit too. I made a short video on exactly this, one join quietly inflating a sum: youtube.com/watch?v=SG-6rtZeizg
putting the grain first is exactly what i wish more plans opened with.
one line like 'one row = one order line' at the top probably settles more fights than another null scan. what worked for a teammate was forcing that sentence into the PR description before anyone looked at the seven checks. then sitting a few rows at that grain next to the total made the quiet join blowups obvious. i'll check your video on the inflated sum, that failure mode is the one i keep underestimating.
Putting it in the PR description is a smart forcing function, because it's the one place nobody skips. I'm stealing that. The same line works as a UAT entry criterion: no grain sentence, no testing starts. Hope the video is useful, and tell me if the fan-out example looks like the blowups you've seen.
Making the grain sentence a hard entry gate is sharper than leaving it as advice.
We tried the soft version first and people still skipped it under deadline. Once testing could not start without that one line in the PR, the fan-out cases showed up earlier, usually as an order-line total that quietly matched invoice count. Your video's blowup shape is the same one we keep walking into.