> 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/guides/capture-a-baseline.md). # How to Create Baselines Tests for your Endpoints ### Introduction A baseline is a test that records how an endpoint behaves against your running stack, and the reference point Kerno uses to detect changes later. Kerno captures one by analysing the endpoint, writing a set of tests, and running them against your app to capture its actual responses. In this guide, you will list your endpoints, generate baseline tests for one and review the plan, then run them to capture the baseline. ### Prerequisites Before you begin, you will need: * Your application running, with Kerno pointed at it. See Connect your app to Kerno. * The environment reporting `ready_for_endpoint_test`. ### Step 1. Listing your endpoints Ask your agent to list the endpoints Kerno found: ``` Use Kerno to list the endpoints in this app. ``` You get the HTTP routes Kerno discovered, grouped by the file that img whether it already has baseline tests. {% hint style="warning" %} In a large app, listing every route can return thousands of endpointsrt you care about, such as a single file or one endpoint. {% endhint %} Narrow it to a single file: ``` Use Kerno to list the endpoints in src/routes/users.ts. ``` Or a single endpoint: ``` Use Kerno to list POST /users. ``` ### Step 2. Generating baseline tests for an endpoint Pick an endpoint and ask your agent to generate baseline tests for it: ``` Use Kerno to generate baseline tests for POST /users. ``` Before it starts, your agent confirms two choices with you, unless you have already set them in your rules: * **Effort.** How hard Kerno works to prove each test is solid. `low` writes and runs each test once. `medium` runs it twice to prove it is repeatable. `high`, the default, adds an iterative pass that critiques and repairs each test until it holds up. Higher effort takes longer and produces sturdier tests. See Testing modes. * **Test types.** Validation tests, security tests, or both. Validation, the default, checks that the endpoint behaves correctly. Security adds an OWASP assessment and writes tests that probe for vulnerabilities. With those set, Kerno analyses the endpoint, works out how it authenticates and what it depends on, and plans a set of scenarios covering the happy path, error handling, edge cases, and authorization. It then stops to show you the plan. #### 2.1 Covering multiple endpoints You can cover several endpoints in one go. Ask your agent to work through a group of them, or a whole file: ``` Use Kerno to create baseline tests for all the endpoints in my users API. ``` Kerno handles one endpoint per run, so your agent goes through them ih plan for your approval before moving on to the next. ### Step 3. Reviewing the plan The plan is Kerno's read of your endpoint. It lists the test scenarios Kerno intends to write, each with the situation to set up, the request to send, and the response it expects. Reading it is the point of this step, because it shows you what Kerno believes your endpoint does before it writes any code. Approve the plan and Kerno starts implementing: ``` Looks good, go ahead. ``` Or send it back with changes. You can drop scenarios, add new ones Kerno missed, or ask for something specific: ``` Drop the pagination test and add one for a duplicate email. ``` ``` Add a scenario that checks a non-admin cannot create a user. ``` Sending it back re-plans with your feedback and shows you a new plan. You can iterate as many times as you need. {% hint style="info" %} Changes you make to a plan apply to the current run. The feedback Kerno carries between runs is the decisions you make on results, like telling it a finding is intended so it stops flagging that endpoint, along with what it learns about your endpoint such as how to authenticate. See Memory and learning. {% endhint %} Approving is what tells Kerno to write and implement the test scenarios. ### Step 4. Letting Kerno implement and run Once you approve, Kerno writes each scenario and runs it against your application, repeating until it passes. Tes scenarios land under `.kerno/scenarios/endpoints/` as TypeScript files. Before it runs anything, Kerno checks its **preconditions**, a set of read-only readiness checks that confirm it can actually test the endpoint. They verify the endpoint is reachable, the intended user can authenticate, any required environment variables are set, and expected seed data exists. When you have given Kerno datastore access, they also confirm each dependency is reachable. Being read-only, they establish readiness without changing your data, and they leave what the endpoint should do for the tests to decide. If Kerno cannot satisfy the preconditions, it stops and tells you what it needs, such as a schema it could not derive, a credential, or a dependency it could not reach, so you can provide it and run again. {% hint style="info" %} Kerno always writes test 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 %} ### Step 5. Reading the result Kerno reports each scenario as one of: * **passed** means the scenario ran and recorded the endpoint's behaviour as your baseline. * **failed** means Kerno wrote the scenario and ran it, but it did not pass. Kerno reports what went wrong so you can fix the cause and run it again. * **blocked** means the scenario could not run because a precondition or capability it needs is missing, so nothing was tested. Often it needs direct database access that is not configured, and Kerno tells you which dependency to add to unblock it. {% hint style="info" %} You may occasionally see **not implemented**. This means Kerno could not produce a working scenario for a case and left the placeholder from the plan in place, rather than counting it as a pass. Nothing was tested. {% endhint %} A baseline captures how your endpoint behaves today, including any bugs it currently has. Once your tests pass, read through the recorded responses and confirm they are what the endpoint should return. If they look right, your baseline is ready. If something is wrong, fix your code and run the baseline again so it records the corrected behaviour. #### 5.1 Potential bugs A scenario that passed can also carry a **potential bug**. Kerno found the endpoint doing something the plan did not expect, confirmed it against your source, and wrote the test to document the real behaviour. The note explains the root cause and what a future change would mean. If the behaviour is known or intended, tell your agent to ignore it, and Kerno stops flagging it on that endpoint: ``` The role field on GET /users/:id is intentional, we return it for backwards compatibility. Have Kerno ignore that potential bug. ``` ### Editing baseline tests To change what a baseline test does, ask your agent to update it rather than editing the file by hand. Kerno rewrites the test and re-runs it against your app, so the baseline still reflects real behaviour. ``` Use Kerno to update the baseline tests for POST /users. The response no longer includes the role field. ``` ### Next Steps You now have baseline tests capturing how your endpoint behave today. From here, Kerno re-runs them each time you change code and tells you what moved, so a regression surfaces the moment it appears.