Scenarios and Baselines
Understand how Kerno generates test scenarios for your endpoints, captures baselines, and keeps both in sync as your code evolves.
Scenarios
Scenarios are the test cases Kerno generates for your endpoints. Each scenario describes what state to set up, what request to send, what response to expect, and how to verify side effects. Scenarios live under .kerno/scenarios/ in your repository as TypeScript files.
Kerno always generates scenarios in TypeScript, regardless of your application's language.
A scenario runs in four phases.
Arrange. Set up any state the test needs (seed a user, sign a JWT, insert a row).
Act. Make the subject HTTP call to the endpoint under test.
Assert. Check the response and any observable side effects.
Clean up. Tear down test data and close connections.
Each scenario also exports a baseline describing the expected response shape, including dynamic values (IDs, tokens, timestamps) marked with {{dynamic}} placeholders so they do not trigger false diffs on every run.
Baselines
Each scenario exports a baseline: a snapshot of what your endpoint actually returned when the scenario last passed.
When capturing the baseline for the first time, Kerno runs each scenario twice. Fields that produce different values across the two runs are automatically marked with {{dynamic}} placeholders. Those fields are excluded from all future comparisons so IDs, tokens, and timestamps never cause false diffs.
On subsequent validation runs, Kerno compares results against the stored baseline in two passes. First, a structural check compares status codes, JSON shape, and field types. If that detects a diff, a semantic pass determines whether the change is meaningful. Accept a diff and the baseline updates. reject a diff and the baseline stays.
What scenarios cover
Kerno generates scenarios that cover common behavioral dimensions, including:
Functional API Workflows
Covers endpoint behaviour, multi step request sequences, coordinated service interactions, and integration patterns across services.
Contract & Schema Validation
Checks request and response structures, data types, required fields, serialization rules, and version compatibility for the API.
Error Handling & Resilience
Validates status codes, error body formats, retry behaviour, backoff procedures, timeout handling, and controlled fallback behaviour.
Authorization & Authentication
Reviews token validation, role based access rules, permission scopes, session handling, and all credential related flows.
Boundary & Edge Cases
Examines 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.
Coverage
Coverage is the share of detected endpoints that have at least one scenario:
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. The meaningful question is whether any change you make gets validated.
Self-healing
As your codebase evolves, Kerno keeps your scenarios in sync automatically. On each validation run, Kerno evaluates every scenario against the current code and assigns it one of four states:
Keep. The scenario is still valid. No changes needed.
Check. The endpoint contract changed. Kerno updates the scenario to match.
Remove. The endpoint no longer exists. Kerno retires the scenario.
Add. A new endpoint was detected. Kerno generates scenarios for it.
Kerno never modifies your application code. Self-healing only touches files under .kerno/. It runs automatically as part of the validation cycle. See Change Validation for how approval triggers these updates.
Last updated