> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/core-concepts/scenarios-and-baselines.md). # Scenarios and Baselines ### Scenarios Scenarios are the test cases Kerno generates for your endpoints. Each one describes what state to set up, what request to send, what response to expect, and how to verify side effects. They live under `.kerno/scenarios/endpoints/` in your repository as TypeScript files, and are meant to be committed alongside your code. {% hint style="info" %} Kerno always writes scenarios in TypeScript, whatever language your application is written in. They reach your app over HTTP, so the language of your service does not matter. {% endhint %} A scenario runs in four phases. * **Arrange.** Set up any state the test needs — seed a user, obtain a token, insert a row. * **Act.** Make the request to the endpoint under test. * **Assert.** Check the response and any observable side effects. * **Clean up.** Tear down test data and close connections. Preconditions that several scenarios share are factored out, so setting up a logged-in user is written once rather than repeated in every test. ### Baselines A baseline is the record of how your endpoint actually behaves. It is not a separate file or a separate step — it is the assert phase of the scenario itself. Each assertion carries a clue explaining what it checks. When a run does not match, every assertion still runs, so one run reports every difference with its own clue and diff rather than stopping at the first mismatch. **Expected values are derived from your code, not guessed.** Kerno traces where each field in a response comes from. A value your handler produces deterministically is pinned exactly. A value that legitimately varies between runs — a generated id, a token, a timestamp — is matched by shape instead, so it never causes false failures. **Assertions are closed.** Each artifact is checked against its full expected shape, covering every field it actually returns. This means a field that *appears* where none was expected fails the scenario even though nobody wrote an assertion for it. That is deliberate: it is how an accidentally leaked field gets caught. ### What scenarios cover Kerno generates scenarios that cover common behavioral dimensions, including:
CategoryDescription
Functional API WorkflowsCovers endpoint behaviour, multi step request sequences, coordinated service interactions, and integration patterns across services.
Contract & Schema ValidationChecks request and response structures, data types, required fields, serialization rules, and version compatibility for the API.
Error Handling & ResilienceValidates status codes, error body formats, retry behaviour, backoff procedures, timeout handling, and controlled fallback behaviour.
Authorization & AuthenticationReviews token validation, role based access rules, permission scopes, session handling, and all credential related flows.
Boundary & Edge CasesExamines payload size limits, pagination behaviour, null or empty values, malformed inputs, and constraint based validation.
Data Integrity & Persistence

Confirms data consistency, transaction behaviour, idempotent operations,

state handling, and enforcement of database rules.

The exact set varies per endpoint based on what the code requires. Security scenarios are opt-in and covered separately in [Security testing](/docs/core-concepts/security-testing.md). ### What coverage measures Coverage is the share of detected endpoints that have at least one scenario: ``` Coverage = tested endpoints ÷ total endpoints ``` Tested endpoints show a play icon in the Kerno panel; uncovered endpoints show a plus icon. Kerno measures endpoint-level coverage, not branch or statement coverage. ### Changing scenarios after a code change Changes to a scenario suite happen when you ask for them, in one of two ways. * **Update.** For an intentional change to an endpoint. Kerno reads the previous run's failures and the files your change touched, defaults every existing scenario to keep, and edits only what your change requires. Your existing scenarios are not rewritten, and the happy path is never removed. * **Generate.** To restart an endpoint's coverage. This replaces the existing plan, so review it before confirming. ### How Kerno avoids false passes Scenarios execute in Kerno's sandbox, not inside your coding agent's context. A verdict comes from what the assertions actually did against your running application, rather than from the agent's report of its own work. Two mechanisms guard the scenarios themselves. * **Every scenario is proven repeatable.** At `medium` effort and above, each one runs twice in a row, so a scenario that only passed because of leftover state gets caught. * **Every scenario is reviewed adversarially.** At the default `high` effort, the finished scenario goes through a critique loop that judges it against what the plan asked for and sends it back for repair until it holds up. It rejects assertions weakened or made tautological to force a green run, errors swallowed by an empty catch, assert phases that check less than the plan's postconditions demand, matches loose enough to pass on the wrong value, arrange phases that never established the precondition they claim, hardcoded identifiers where each run needs a fresh one, and teardown that says it deleted something without verifying it did. Endpoints themselves are found deterministically rather than guessed, which is what makes the target of all this trustworthy. See [Codebase indexing](/docs/core-concepts/codebase-indexing.md) and [Testing modes](/docs/references/testing-modes.md). ### Verdicts Each scenario reports one of four verdicts. * **Passed** — the scenario ran and the endpoint behaved as expected. * **Failed** — the endpoint did something the scenario did not expect. * **Blocked** — the scenario could not run, usually because a dependency it needs is not configured. Blocked is neither a pass nor a fail; nothing was tested. * **Not implemented** — Kerno could not produce a working scenario for this case. This is reported honestly rather than counted as a pass. A passing scenario may also carry a **potential bug**, where Kerno found the endpoint doing something unexpected, confirmed it against your source, and documented the real behaviour. See [Security testing](/docs/core-concepts/security-testing.md) for how to review and dismiss these.