bar chart
Expected change in approval rows per probe
The first call adds one row; the replay and the conflicting call add none.
All green: that was the report after the ordering system wrote its first real fact. Then I read the code behind it, and a chunk of the green was paint.
Until this step, my system only made proposals. It paired products from the stores' sales feed with my own products and put a few in a review queue. This step is the first one that counts. A person says "this outside product is that product of mine," and the rest of the system will trust it. So I kept it to one item, one existing product and one approval.
Three places that can say no
The run checks first. The queue item must still be waiting for review, the product must be active, and the stored records must point at each other. If not, it stops with a fixed error code and writes nothing.
Then the request has to pass a contract. It needs a real person's name, proof from two kinds of sighting, and no raw data from the feed. A matching name is not proof. The feed's product ID can't be used as mine.
Then the database. It allows one approval per queue item and one active approval per outside product, and it writes the approval and its evidence in one go.
Retry, conflict, and counting
The request ID is built from its content, so a rerun builds the same request. Same key and same content is a replay. Same key and different content is a conflict, and nothing gets written.
To prove the write was small, the run counts rows in a couple dozen tables before the write, after it, after a replay, and after a conflicting request. Only the approval tables should grow, and only once. It ran once on my VM and got exactly that.
The green nobody checked
Some "this didn't happen" lines came from the counts. Others were hard-coded.
That line was simply written as false and never checked.
I think those lines are true. But the report shows them the same way as the measured ones, and the test checks them too, so it can't fail on them. That's my mistake.
The good part: the run makes broken copies of the real request, with no person, a name-only proof, or the feed's ID, and checks that each one is refused. That's a real test. Its limit is that "name-only proof" is something the request says about itself, so a request that hides it gets through.
What counting can't show
Counts show rows added or removed. They miss a row that was edited. They only compare the first and last count, so an add and a delete in between would cancel out. And they only cover tables someone put on the list.