Test in Studio first
The API Explorer (Data → API Explorer) sends real requests. Under Application-user authentication sign in as a test user (email, password, MFA code) and the request goes out with that person’s token. Try the same request as:- A signed-in user who should pass.
- A signed-in user who shouldn’t (someone else’s record).
- Nobody (clear the authentication).
A test harness (code)
Create test users once indevelopment in Studio (Users & auth → People → Users → New user; see Users), keep their credentials in your test configuration, and sign in per test:
A table of cases per rule
For every table, write the rows of this table and a test for each:Test the edges
These are where real bugs hide:- The caller has no organization and a record has none (null equals null).
- A record with a null date against
lte [..., "$now"]. - A role that was just changed: sign out and in, or wait for refresh.
- Two organizations: a user in both, acting in one.
- A record created by a server with no owner.
- Related records:
expanda relation whose table has stricter rules. - Realtime: subscribe as Bob; Ada’s change must not arrive.
- Files: upload under someone else’s prefix.
Reading refusals
Compare with a secret key
If a call fails and you think it shouldn’t, repeat it with a secret key on a server. Success means a rule was the cause; failure means something else (validation, a missing table).Run rule tests in CI
Keep the harness in your repository and run it against adevelopment or preview environment on each change to rules, just like unit tests. A changed named rule can alter a dozen tables at once; the tests tell you.
After you change a rule
- Run the cases.
- Check Activity for unexpected 403s in the hour after you ship.
- For a named rule used widely, move tables over one at a time (Named rules).
Debugging
Find the rule that said no.
Mistakes
What to avoid.