Test Prompts
How to ask the agent to test your project — concrete prompt patterns and examples.
Tests in Airbuild are created the same way everything is created: through an instruction in chat. You don't install test frameworks, write configuration, or set up CI — you describe what you want checked, and the agent writes tests, runs them, and reports back.
What the agent can test for you
- Backend endpoints — all routes or individual ones, with valid/invalid payloads, edge cases
- Database logic — queries, constraints, migrations, rollbacks
- Frontend flows — click paths, forms, error states, mobile layouts
- Authentication — login/logout, session expiry, permission checks
- External integrations — Stripe webhooks, Brevo emails, GitHub sync (with mocks)
- Performance — load times, N+1 queries, bundle size
- Security — CSRF, XSS, SQL injection, missing auth checks
Concrete prompt examples
Full-coverage test of a backend:
Please test all endpoints for me. For each one: one happy path, one validation error, one auth error. Show me a table at the end of what passed and what didn't.
Specific endpoint:
Write pytest tests for /api/orders — POST with valid and invalid data, plus a test that only the owner can see the order.Form validation in the frontend:
Click through the signup form. Check what happens when the email field is empty, when the password is too short, when both fields are valid.
Migration safety:
Before we deploy migration V012 — test the rollback paths and write me a test that no old records get lost.
Light load test:
Run a short stress test against /api/search with 100 parallel requests. How does p95 latency look? Any memory leaks?What the agent does automatically afterwards
- Writes test code — pytest for backend, Vitest/Playwright for frontend, depending on project type
- Stores them under `tests/` — separate folders for
unit/,integration/,e2e/ - Runs them — directly in the workspace, you see pass/fail in the console
- Summarizes — short report in chat: what was tested, what failed, suggested fixes
Tips for good test prompts
- Say what matters — *the Stripe webhook must never run twice* gives the agent a concrete property to check
- Say what you DON'T want — *no mocks for the DB, I want to test against a real Postgres instance*
- Ask for coverage — *generate coverage-html at the end and tell me where we're under 70%*
- Repeatability — *the test must be deterministic across runs — no flaky sleeps or Date.now()*
Where the results show up
Tests run in the Tests tab: results per test grouped by file, line-level coverage, run history, and a live progress card in the chat while a run is going. The tab appears once the testing integration is enabled.
A failing suite does **not** block a release by default — that is a per-project switch in Settings. The checks that do block a publish are a separate, always-on set. Both are described in Quality Assurance.
More in the sub-pages: Backend & APIs, Frontend & UI, Auto-Fix & Pre-Flight.