Skip to main content

​
At a glance

​
What you can do from where

✓ = supported, — = not available from that interface.

​
Entry points

  • Detection is part of generation: a generation session started from the REST API, MCP, a PR comment, or Slack detects what to test and writes the tests in the same session. Running detection separately in the web app is optional.
  • Auth: REST calls send Authorization: Bearer $CHECKSUM_API_KEY (API keys). MCP clients sign in through the browser or use the same key (MCP server).
  • PRs need all three: Checksum opens a PR only when it has the pull request number, repository, and head branch.
  • Output: a story file (.checksum.md) and a Playwright test (.checksum.spec.ts) per flow, delivered as a PR to the tests repository (Story & Test Format).
Developer guide
Starting generation from your own tools

​
Start generation from your own tools

You don’t need the web app to create tests. Developers usually start from one of these:
  • REST API: have a release bot or CI step send a pull request to Checksum and wait for the tests. See Generate Tests → REST API.
  • A pull request comment: type /checksum generate on the PR, or ask Checksum to generate for every new PR automatically. See Ask from a pull request.
  • Your coding agent: with the MCP server connected, ask “Generate Checksum tests for this PR.” See Coding Agents & MCP.
  • Slack: mention @checksum in the thread where the feature was discussed. See Mention @checksum in Slack.
Detection happens as part of generationWhen you start generation from any of these, the agent detects what to test and generates the tests in the same session. You don’t need to run detection in the web app first.
The full entry-point table and capability matrix are in the “Reference for AI: test generation capabilities by interface” block under At a glance (capability matrix). The generation REST API spec (fields, types, responses, errors) is in Generate Tests → Reference for AI: generation REST API. MCP tool inputs are in Generate Tests → Reference for AI: checksum_test_generate.
▦
In the Checksum web app
Collections and test flows

​
Collections and test flows

Two objects organize the work in the web app: A flow can come from detection, be written manually, be implied by a pull request, or be recorded. PR-based triggers (GitHub, REST API, MCP) generate from the PR diff without a saved flow. A walkthrough recorded with the Chrome extension is used as context for the agent, which generates one test or, split into flows, a whole batch of tests from it.
A detected test flow card showing title, description, and start URL

A test flow in a collection: title, steps, and start URL.

i
How it works
The lifecycle every test goes through

​
The generation lifecycle

Every test in your suite goes through the same stages, whichever tool you use to start them:
1 · DetectAgent proposes the flows worth testing
→
2 · Review flowsEdit, delete, or add flows
→
3 · GenerateStory + Playwright test written
→
4 · VerifyAgent runs the tests to prove they pass
→
5 · PRDelivered to your tests repo
→
6 · MergeYou review and merge
→
7 · MaintainAuto-recovery + auto-healing
1

Detect

Detection analyzes your application, including its source code, and proposes test flows: key user journeys, critical business flows, and edge cases. This step is optional. You can also write flows by hand, generate straight from a pull request, or record a walkthrough with the Chrome extension.
2

Review flows

Detected flows land in a collection. Check the titles, steps, and start URLs, remove what isn’t relevant, and add any flows the agent missed. This is where you prioritize before any code is written.
3

Generate

Generation starts an agent session that writes a story file (.checksum.md) and a Playwright test (.checksum.spec.ts) for each flow. In Deep mode it first interviews you and builds a plan.
4

Verify

The agent reviews its own work, validates it against the Checksum CLI (“Checksumify”), and runs the tests against your environment. Only passing tests are delivered.
5

Pull request

Checksum opens a PR on a new branch in your tests repository. The PR description explains the flow being covered.
6

Merge

You review the PR like any other change. Your repository is always the source of truth (see Test Repository & Config).
7

Maintain

Once merged, tests run in CI or on demand (Running Tests). Auto-recovery handles small UI drift at runtime, and auto-healing opens PRs to fix tests that break as your app evolves.

​
Which path should I use?

Web app

Run detection per collection, review and prioritize flows, then generate in batches. Use Deep mode the first time you cover a complex area. This is the best place to curate coverage by feature.

GitHub or MCP

Comment /checksum generate on your PR, or ask your coding agent: “Generate Checksum tests for this PR.” The tests come back as a PR, and progress shows in a sticky comment.

REST API

Call POST /auto-generate from a release bot or CI step, then poll the batch. You can pass a preview URL with envOverrides. Or ask Checksum to turn on auto-generate on PR open.

Slack

Mention @checksum in the thread where the feature was discussed. The whole thread becomes the agent’s instructions.

Chrome extension

Record yourself clicking through a flow with Checksum Capture, and narrate the edge cases, assertions, and variations you want. Split into flows, one recording can produce a batch of 10, 20, 30 or more tests.

​
Before you generate

Generation needs a working project: an environment URL and test users, a connected tests repository, and your source code repository. Checksum sets these up with you during onboarding (see Onboarding & Proof of Value). Once you’re live, you can manage them yourself:

​
In this section

Detect Test Flows

Let the agent propose what to test.

Generate Tests

Every trigger: app, API, GitHub, Slack, MCP, Chrome extension.

Deep vs Standard

Speed vs thoroughness, across every pipeline.

Story & Test Format

What lands in your repo.

Agent Sessions

Lifecycle, questions, approvals, steering.