Testing your app
What to test and with which tool: access rules, migrations, functions, realtime and the whole app against a staging environment with seeded data and test users.
| What | Test it with | Writes anything? |
|---|---|---|
| Who can do what (access policies) | sov rules test — your own cases (Access rules tests) | No |
| Every kind of user against every resource | sov sim run — a full simulation (Simulate access before you ship) | No |
| One request | sov policy check --action sql:select --resource orders | No |
| Realtime access | sov realtime dry-run <channel> --action PUBLISH --user <user-id> | No |
| Migrations | sov db migrations push --dry-run (each runs in a transaction that is rolled back) | No |
| Functions on your machine | sov fn serve ./functions --env-file .env.test | Only what your code does |
| A deployed function | sov fn invoke <name> --simulate --data '{…}' — its Sovaria calls are checked, then rolled back or refused | No |
| The whole app | Your own end-to-end tests against a staging environment | Yes, in staging |
Test against staging, not production
A staging environment has production's structure — tables, policies, functions — with no rows and its own URL (Environments, staging and deploying to production). Point your test app at its URL from Connect, and use a separate key for it.
Seed data
Keep seed SQL in
sovaria/seeds/and load it into the environment.sov db seed --env <staging-env-id> # runs sovaria/seeds/*.sql sov db seed --file sovaria/seeds/demo.sql --env <staging-env-id>Create test users
Sign them up through your app, or add them under Authentication › Users (Add user) or with
sov auth-product create --email qa+1@example.com. Use addresses you control.Run your tests
Sign in as each test user in your end-to-end tests and check both what they can do and what they must not see.
Functions
sov fn serveruns functions locally like production, with the same time and memory limits (--timeout,--memory) and secrets from--env-file; it reloads as you save (Local development, logs and streaming).sov fn triggers test <trigger-id>sends a sample event through a trigger (it counts as one invocation).- Write handlers you can call directly from a unit test: keep the logic in plain functions and the
handlerthin.
Smoke checks
sov test --smoke runs built-in checks against the linked project; sov test --path tests/ runs your pytest suite. Run both after a deploy.
In CI
Run the checks that write nothing on every pull request, and the end-to-end tests against staging before promoting — CI/CD.