How to Create Baseline Tests for your Entry Points

Learn how to generate baseline tests for an entry point, review the plan, and run them to capture how your app behaves.

Introduction

A baseline is a test that records how an entry point behaves against your running stack, and the reference point Kerno uses to detect changes later. Kerno captures one by analysing the entry point, writing a set of tests, and running them against your app to capture its actual responses.

In this guide, you will list your entry points, 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 How to Configure the Kerno Test Environment.

• The environment reporting ready_for_endpoint_test.

Step 1. Listing your entry points

Ask your agent to list the entry points Kerno found:

Use Kerno to list the entry points in this app.

You get the entry points Kerno discovered, such as HTTP routes, background consumers and MCP tools, grouped by the file that defines them, each one showing whether it already has baseline tests.

In a large app, listing everything can return thousands of entry points. Narrow it with a scope to the part you care about, such as a single file or one entry point.

Narrow it to a single file:

Use Kerno to list the entry points in src/routes/users.ts.

Or a single route:

Use Kerno to list POST /users.

Step 2. Generating baseline tests for an entry point

Pick an entry point 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 three choices with you, unless you have already stated them in the chat or in your agent's rules file:

• 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. An entry point your team marked as critical in the Kerno Portal always runs at high, whatever you choose. See Testing modes.

• Testing mode. White box, the default, lets Kerno use the dependency access you configured to set up and check state directly. Black box limits it to calling your app like any external client. See Testing modes.

• Test types. Validation tests, security tests, or both. Validation, the default, checks that the entry point behaves correctly. Security assesses the entry point against the OWASP Top 10 and writes tests that probe for vulnerabilities. Asking for security on its own narrows the run to the happy path plus those vulnerability tests, so ask for both when you want your functional coverage as well. See Security testing.

With those set, Kerno analyses the entry point, 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 entry points

You can cover several entry points 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 entry points in my users API.

Your agent can cover them one at a time, approving each plan before moving to the next, or dispatch the whole group in a single batch. See Testing many entry points in one call.

Step 3. Reviewing the plan

The plan is Kerno's read of your entry point. 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 entry point 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.

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 entry point, along with what it learns about your entry point such as how to authenticate. See Memory and learning.

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 readiness checks that confirm it can actually test the entry point. They verify the entry point is reachable, the intended user can authenticate, any required environment variables are set, and expected seed data exists. Whether your dependencies are up is the job of the environment healthcheck. The checks read your data and change nothing, apart from one case. If you have not given Kerno a working test login, they may create a throwaway test user, through your app's signup route when there is one. What the entry point should do is left 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 or a credential, so you can provide it and run again.

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.

Kerno writes two files per scenario. The .scenario.md is the one to read, since it describes the scenario in plain English. The .scenario.ts beside it is the executable version the sandbox runs. See Anatomy of a Kerno test.

Step 5. Reading the result

When you are signed in to Kerno, your agent also gives you a link to the run's page in the Kerno Portal, where you can follow it and read the results.

Kerno reports each scenario as one of:

• passed means the scenario ran and recorded the entry point'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.

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.

A baseline captures how your entry point behaves today, including any bugs it currently has. Once your tests pass, read through the recorded responses and confirm they are what the entry point 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 entry point 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 entry point:

The role field on GET /users/:id is intentional, we return it for backwards compatibility. 
Have Kerno ignore that potential bug.

Later runs, including reviews of your code changes, no longer report it. The test file keeps its note about the bug until you ask Kerno to update that entry point's tests. Clearing Kerno's whole cache forgets the decision, and the bug is reported again.

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 entry points 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.