The whitelist versus $hidden point is the one that sticks. A new sensitive column staying private until someone adds it is the safer default. Does the admin users list ever need a field the public shape doesn't have, or do you add a separate admin resource for that?
I do the same at every level, not just the top one. For a nested user I first assert that data.user is present, then I assert its exact keys, so a missing eager load fails loudly instead of letting the shape check pass over nothing. I apply that same presence-then-shape pair wherever a resource nests another resource, because that is where the quiet pass tends to hide. It adds a few lines per test, but I have caught more missing relations that way than I have caught extra fields.
Presence first then shape at every level makes sense, that's where the quiet pass hides. A few extra lines per test is a cheap price. Do you wrap that pair in a small helper so you don't repeat it, or do you just write it out each time?
I write it out each time, honestly. I tried a helper once and the failure message got vague about which level broke, so I kept the two asserts visible in each test. It is a bit repetitive, but when it fails I can see at a glance whether the relation is missing or the shape drifted.
Praneet Brar
Building cool things like launch platforms
The whitelist versus $hidden point is the one that sticks. A new sensitive column staying private until someone adds it is the safer default. Does the admin users list ever need a field the public shape doesn't have, or do you add a separate admin resource for that?