Your app comes with proof
Kliv writes real tests for the apps it builds — and runs them in a real browser, against a disposable copy of your database, with a receipt for every side effect. The same loop that writes your app writes its tests and drives them green.
Built-in testing
Not generated code and crossed fingers
Most AI builders generate an app and hand it over — whether it actually works is your problem. Kliv owns the whole stack the app runs on: the browser, the API, the security rules, the database, the email pipeline. That's what makes proof possible. Tests aren't something you bolt on later; they're part of how the app gets built, run by the same loop that wrote the code.
The anatomy of a run
The best way to understand the testing system is to follow one run from the first line to the verdict. Here is what happens — and what never touches your real data.
Write
The AI writes unit tests as it builds — genuine Vitest and Testing Library, the industry-standard stack, not a proprietary imitation. Ask for a flow to be covered and it writes a Scenario: navigate, click, fill, assert, in semantic terms — the button by its name, the field by its label — not a brittle CSS path that dies in the next redesign.
Run in a real browser
Tests execute in a real browser against your actual app — real rendering, real sign-in, real row-level security. Nothing is mocked that matters: if a permissions change lets one user read another's data, a test fails the way your app would have.
Fork the database
Before a Scenario touches data, it gets a disposable fork of your database — same schema, same rules, none of your rows at risk. Creates, edits, and deletes run for real and land on the fork; your files and commerce state are cloned the same way. When the run ends, the fork is thrown away.
Capture the egress
Emails, webhooks, and third-party calls are captured, not fired. A test can assert that the welcome email went out, to whom, with what — and no email ever leaves the building. Your integrations stay quiet while your logic gets exercised.
The receipt
Every run records what the app actually did: which rows it wrote, which emails it would have sent, which external calls it attempted — each one marked accepted, captured, or refused, with the reason attached, down to the security rule that blocked a write. Not just red or green: what happened, and why.
The verdict
Results come back per check, per file — the failing assertion, the step that broke, alongside the run's receipt. Structured failure is the point: it's what lets the same loop that wrote the code find the mistake, fix it, and run again.
The gate
Test results gate publishing. A failing Scenario stops the release before it reaches your users — so "it worked when we built it" becomes "it works now," verified on every change instead of remembered from the demo.
What the test system knows how to do
Built in, run for you, and readable when you want to look.
The real testing stack
Genuine Vitest, Testing Library, and jest-dom running in the browser — the same tools professional teams use, so the tests read like tests, not like a vendor's dialect.
Scenario tests
End-to-end flows written in semantic terms — find the button by its role, the field by its label — driving the real app the way a user would.
A disposable database
Every Scenario runs against a fork of your real database. Writes are accepted, asserted on, and discarded — your data is never part of the experiment.
Nothing leaks
Test runs capture email, webhooks, and connector calls instead of sending them — you can prove they happened without them happening.
Every run has a receipt
A ledger of every side effect a test caused — accepted, captured, or refused, with the reason. The trace, not just the traffic light.
History and the gate
Runs are tracked over time, and passing tests gate publishing — verification is a standing state of your app, not a one-time event.
Common questions
Who writes the tests?
The AI does, as it builds — unit tests by default, in the standard stack. Ask for a flow to be covered and it writes a Scenario for it. Every test is readable code in your app; you can inspect any of it, and you never have to.
Do tests touch my real data?
No. Scenarios run against a disposable fork of your database — writes are accepted there and thrown away with the fork when the run ends. Files and commerce state are cloned the same way, so even a test that deletes everything deletes nothing.
Will a test send real emails or hit my integrations?
No — outbound traffic is captured, not sent. The run records that the email would have gone out, to whom and with what, and the test can assert on it. Your customers and your connected tools never see a test.
What do I see when a test fails?
Per-check results — the file, the check, the assertion that failed — plus the run's receipt of side effects with the reason each was allowed or refused. That structure is what lets the AI diagnose its own mistake and fix it, instead of guessing from a screenshot.
Do tests exercise my security rules?
Yes — Scenarios run with real sign-in against real row-level rules, not a mocked session. If a change lets a user see data that isn't theirs, the test fails before a user ever could.
Can a failing test block a release?
Yes. Scenario verdicts gate publishing — a red run stops the release until it's green again. The gate is the difference between hoping the last change was safe and knowing it was checked.
Describe your app. Get it proven.
Built-in means built together: tests run against the same app your users see — so a failing checkout test is a failing checkout, not a mock.
