Test an application
A generated project ships independent test suites over the same HTTP surface. All of them are generated from the model, so they grow when the model does.
| Suite | Where | Run |
|---|---|---|
| Rust request suites: the primary gate | backend/tests/ | LOCO_ENV=test cargo test --test app (needs createdb <crate>_test) |
| Bun API suites: shared suites plus two per entity | tests/suites/ | cd tests && bun run test (starts the backend itself) |
| Browser specs (Playwright) | tests/ui/ | E2E_APP_URL=http://localhost:3001 bun run test:ui |
| Smoke test of every screen | tests/smoke.mjs | bun run smoke |
| Everything, in containers | compose profile test | docker compose run --rm e2e and docker compose run --rm e2e-ui |
bun run qa runs the smoke test and then the Rust request suite, starting the backend and front end
if they are not running.
What they check
- Against the model, not the generator. Several API suites read what the model declared (its value lists, state-machine edges and parents) instead of reading back what the generator wrote.
- Access per role. An access oracle carries the compiled access rules and the seeded accounts, so suites sign in as each role and check exactly what it may read, write and press.
- Not only as the administrator. One suite sends no credentials, and one builds an ordinary role, because the administrator passes every check.
- The screens. The smoke test fails on a crashed screen, a server error, a console error or an internal table name shown to a user.
The generated backend is also expected to pass cargo clippy --all-targets -- -D warnings.