The fallback you hope never runs
We moved eleven reads into one request and kept the old path for the day the batch is refused. A spare path is only safe if it answers the same thing.
When we changed the till menu to fetch its eleven plain reads as a single database request, we kept the old way of doing it underneath. If the batch is refused for any reason, the route runs the same eleven statements one by one, exactly as it did the day before. The sign-in gate has worked like that for months and so does the check that decides whether a dish can be deleted or must be archived. A database that will not take a batch should slow the product down, not take the menu off the counter.
A spare path like that is comforting to write and dangerous to leave unproven, because by design nobody will see it run. The batch works, the fallback sits there, and the first time it fires is the first time anyone learns whether it answers the same thing.
Run both, compare the answers
So the test does not trust it. It builds the venue from scratch in a real SQLite behind a face that behaves like our database: three dishes in two sections, a cheese question on the burger, a month of one dish selling, a section photograph of the venue's own, a surcharge on the till and a setting for the add-on row. It runs the route with the batch working and keeps the whole reply. Then it runs the route again with the batch forced to fail, counts that the fallback really did make twenty-two separate requests, and compares the second reply to the first, field by field, down to the order of the items.
Then it checks the reply is a menu and not two empty objects agreeing with each other: the seven portions left of fries, the barcode on the burger, the compact list of question ids on each dish, the venue's own photograph of the Sides section layered over the shared palette colour for Mains, the ten percent service charge, the late-night surcharge, the add-on row set to the venue's own picks. A test that only said the two paths matched would pass if both paths returned nothing.
Make it fail the way it would fail
One of the eleven reads is optional. It asks a small table that holds a per-surface override for the add-on row, and a venue on a database that does not have that table yet is entitled to its menu regardless. In a batch, one statement naming a missing table fails the whole batch. So the last test drops that table and calls the route. The batch is tried first and refused, the fallback runs the other ten, the optional one answers empty, and the menu comes back with its surcharges and its service charge intact. That is the exact failure the fallback exists for, made to happen on purpose.
Three of the first attempts at this test failed for reasons that had nothing to do with the route: a column the seed left null that the schema requires, a colour column with a different name from the one we guessed, and an item order that follows the venue's own section list rather than the alphabet. Every one of those was the test being wrong, and every one was found by the harness before a byte shipped. A fallback proven that way is one you can stop hoping about.