Skip to main content

Create Performance Tests

In brief: Create-perf-tests writes scenario-linked k6 journeys (and composites only with membership approval) from PR, last-run, or release-git-range scope using redacted REAL E2E shapes and relative TrueCoverage demand—never absolute load.

:::tip Authoritative product docs Performance Testing · organization · when to use which workflow. This page is the agent playbook. :::

Create Performance Tests (workflow-id: create-perf-tests) is the authoring analog of Create tests—for k6, not Playwright. Policy-backed. Nests init-perf when k6/ is missing.

When to use​

  • After a PR that changes a hot path, operation, or scenario with no matching k6 journey.
  • On the default branch, to close gaps since the last create-perf-tests run.
  • Nested under run-perf-tests when a release git range is insufficiently covered—and you said yes to authoring.

Do not use it merely to execute existing files (that is run-perf-tests), to raise VUs from TrueCoverage, or to silently reweight a composite. Prefer upkeep-perf when the files exist but links, mocks, or membership are stale.

Prompt​

/testchimp create-perf-tests
/testchimp create-perf-tests for checkout
/testchimp create performance tests

Synonyms: /testchimp create-perf-tests, /testchimp create performance tests.

Scope​

Optional. When omitted:

  • Feature / PR branch — scenarios, operations, and paths implicated by the diff.
  • Default branch — since the last create-perf-tests run (or ask for a history window).

Pass a feature area (for checkout) or plans path to constrain the queue. Nested release authoring must stay on the same prior SHA → cut SHA range as the parent run-perf-tests plan—do not expand to the whole repo.

Prerequisites​

  • Org capability PERFORMANCE_TESTING (or trial).
  • connect-to-test-env for a runnable environment (smoke validation).
  • Mapped tests + plans roots. Platform-provisioned #TS-… ordinals only—never invent scenario ids.
  • k6 scaffold (k6/) or nested init-perf in the same approval.

Policy​

  • create-perf-tests.policy.md — authoring conventions, scenario priority / semantic coverage, composite rules.
  • run-perf-tests.policy.md — capacity model and dependency mock/latency inventory (needed so authored journeys do not invent load).
  • global.policy.md — scenario priority and semantic-coverage flags.

How to use​

  1. Invoke the prompt (optionally with a focus area). Approve the plan before any file is written.

  2. Expect the plan to list candidate #TS-… ids, journey files, load vs volume independently, seed/teardown, outbound mocks with realistic latency, and any composite membership question:

    Add <journey-id> to composite <composite-id> with relative weight <weight>? This changes only the mix; confirm the composite profile's absolute VUs/RPS/duration separately.

  3. After Execute, journeys live under k6/journeys/ with export const testchimp metadata. Profiles stay smoke until you approve load/volume numbers.

  4. Run them with /testchimp run-perf-tests (or the wrappers in organization).

What it does​

Plan → approve → Execute:

  1. Soft-gates PERFORMANCE_TESTING. Nested init-perf if k6/ is missing.
  2. Ranks candidates (get-requirement-coverage --include-perf, scenario priority, semantic novelty). When API observability is available, it prioritizes fresh high-p95/p99 operations without current journeys, then high-volume/high-error exposure. TrueCoverage demand is relative ranking only.
  3. Pulls redacted REAL E2E interaction shapes when API contract coverage is available—method, path template, schema shape, status class, timing distribution. Never credentials, cookies, or raw bodies.
  4. Classifies load vs volume independently; plans synthetic seeds via k6/scripts/seed.sh. Volume journeys call pickTenant(), set volumeKind, use 10/50/100 manifests, and run later via k6/scripts/run.sh (one k6 run, volume_size chart).
  5. Inventories SUT outbound deps; stubs with realistic latency (mock-external.js / mock-llm.js / env doubles). Zero-ms stubs are not the load/volume default.
  6. Writes journey files + dataset manifests; writes plans/smart-smoke/<branch>/related-perf-tests.json via select-related.sh. /testchimp run QA also writes that file when k6/journeys already exists.
  7. Composite membership only if that prompt was approved.

Does not derive VUs, RPS, duration, dataset size, SLOs, or thresholds from TestChimp telemetry. Production and k6 p95 values are not directly comparable unless environment, workload, window, dataset, and dependency behavior genuinely match.

Nested from a release run​

Reuse the parent workflow_execution_id and plan file (one extra approval for the authoring checklist). After Execute, run-perf-tests runs the new journeys plus already-related ones with TESTCHIMP_RELEASE set.

See also​

FAQ

Will the agent silently add my journey to a composite?

No. Composite membership and relative weights require an explicit approval prompt. That prompt does not authorize a new VU or RPS budget.

Can create-perf-tests run nested under a release?

Yes—when run-perf-tests finds the release git range uncovered and you agree to author. It reuses the parent plan and stays on prior SHA → cut SHA.

Are production request bodies copied into tests?

No. Only redacted method, path template, schema shape, status class, and timing distributions are retained. Seeds use synthetic data.

Related documentation