k6 Test Maintenance
Maintain, fix, and improve existing k6 test scripts. Five maintenance tasks,
each with a step-by-step procedure in
:
- Threshold tightening -- adjust threshold values based on observed metrics
- Version migration -- update scripts for new k6 releases
- Service change adaptation -- fix tests when the underlying service changes
- Refactoring -- clean up and modernize test code
- Best practices audit -- check scripts against current k6 best practices
Core principle: behavior-aware change control
Classify every proposed change by whether it alters the test's runtime behavior:
- Syntactic (behavior unchanged): the k6 runtime produces identical metrics,
pass/fail results, and endpoints. Examples: rename a variable, → ,
remove unused imports, update comments, reformat. Apply directly.
- Behavioral (behavior differs): anything affecting metrics, pass/fail,
timing, request targets, or load shape. Examples: threshold value changes,
adding , endpoint URL updates, check rewrites, scenario changes, new
thresholds. Always present as a diff with rationale and require confirmation.
The threshold for "behavioral" is deliberately low. If in doubt, treat it as
behavioral and ask -- a trivial-looking threshold change can cascade to CI
gates, SLO calculations, and alerting.
Dependencies
- -- fetch and edit GCk6-hosted scripts safely (§5: GET, backup,
edit, validate, PUT, verify by sha256). Read it before touching any
cloud-hosted script.
- -- sole tool for Grafana Cloud API access.
- mcp-k6 tools -- and . Check
availability first; fall back to if absent.
- CLI -- documentation lookup when mcp-k6 isn't configured.
- CLI -- local validation (, ).
Validation loop (every edit)
Every workflow produces a modified script. Never present or PUT an unvalidated
script -- run this loop, fixing and re-running until it passes:
- Parse-check: -- catches syntax errors, invalid
options, broken imports. Works on all types including browser tests (no
browser needed). If mcp-k6 is available, also run .
- Local smoke (non-browser, service reachable):
k6 run --vus 1 --iterations 1 <script>
.
- Classify the change (below) and verify per the matrix -- recipes in
references/verification.md
.
- Cloud-hosted scripts: apply via the k6-manage §5 safe-edit recipe
(GET → backup → edit → validate → PUT as →
sha256-verify).
Change classification
- Class A -- declarative-config only. The diff is confined to
or similar declarative fields that don't alter what the
k6 runtime executes; the bytes inside , imported modules,
and check predicates are byte-identical. Example: → .
- Class B -- runtime logic changes. Any change to ,
imports, helper modules, request URLs, check predicates, or to
/// (which alter load shape
and metric distributions). Example: changing a URL, adding a check, rewriting
auth, switching executors.
When in doubt, treat as Class B.
Verification matrix
| Class | Test duration | Verification |
|---|
| A | any | sha256 + + historical pass/fail prediction. No cloud run needed. |
| B | short (< 5 min) | sha256 + + full cloud run (k6-manage §11). |
| B | long (≥ 5 min) | sha256 + + local 1-iteration smoke + of a local copy with . PUT to the saved test only after the cloud smoke passes. |
Verification depth depends on the change class, not the test's duration -- most
edits don't need a full run, and production tests may run for hours. Per-class
recipes (Class A prediction table, Class B short/long, edge cases like scenario
changes and loosening) are in
references/verification.md
.
Documentation lookup
Before proposing any change that touches k6 APIs, imports, or patterns, confirm
it against current docs and cite the source in your report -- this grounds
recommendations in the real API, not stale model knowledge. Look up in order:
- mcp-k6 (preferred):
get_documentation("best_practices")
,
get_documentation("javascript-api/k6-browser")
, .
- CLI (always available):
bash
k6 x docs using-k6 thresholds
k6 x docs javascript-api k6-http
k6 x docs search "websocket migration"
2-call strategy: try the direct path first; if it returns a topic list, pick
the subtopic and call again. Full parent paths required (,
not ). serves docs for the installed k6 version -- it
may lag the target version when migrating.
- Web fetch (last resort):
https://grafana.com/docs/k6/latest/
.
Async check pattern
A common browser-test bug: using
from
with async predicates. The
built-in
does not await Promises, so
check(page, { 'title': p => p.locator('h1').textContent() === 'Foo' })
silently
passes because the Promise object is truthy. Two valid fixes:
- Async-aware check from jslib:
import { check } from 'https://jslib.k6.io/k6-utils/1.5.0/index.js'
-- then
predicates can be and inside them works.
- Resolve the value before the check:
const text = await page.locator('h1').textContent(); check(text, { ... })
--
keeps the standard sync from .
When you hit this during any workflow (migration, refactor, audit), flag it as a
behavioral bug and propose one of these fixes.
Script sources
- GCk6-hosted -- fetched and pushed via §5 (GET → backup → edit →
validate → PUT → verify sha256).
- Local on disk -- read and edit directly. Validate before presenting.
Determine the source before starting: a GCk6 test URL or ID is cloud-hosted; a
file path is local.
Workflows
- Threshold tightening --
propose values with observed-metric justification, diff, apply, Class A verify.
- Version migration -- find
deprecated/renamed APIs, classify syntactic vs behavioral, apply, Class B verify.
- Service change adaptation
-- map each service change to a script change, propose fixes, Class B verify.
- Refactoring -- find issues,
auto-apply syntactic, propose behavioral, Class B verify after confirmation.
- Best practices audit --
doc-driven audit across thresholds, load design, resource management, code
quality, and browser specifics.
All five follow behavior-aware change control: auto-apply syntactic changes,
present behavioral ones as diffs for confirmation.
Gotchas
| Issue | Detail |
|---|
| Cloud script format | GCk6 scripts can be single files or tar archives. Detect with before editing (see k6-manage §5). |
| Zero-observation thresholds | A threshold on a metric with no observations passes by default. When adding new thresholds, ensure the metric is actually emitted by the test. |
| abortOnFail cascades | If a threshold has , tightening it means runs abort earlier. Warn the user. |
| Browser script validation | Browser scripts can't be validated with without a browser. Use for parse-only validation, or via mcp-k6. |
| k6 x docs version alignment | serves docs for the installed k6 version; when migrating to a newer version, local docs may not reflect the target API. Note this in migration lookups. |
| Script drift after edit | After pushing a cloud-hosted script, the next run uses the new version, but historical runs keep their bundled snapshot. To investigate a past failure, compare the run-bundled script (read-only), not the current one. |
References
- -- step-by-step procedures for the five maintenance tasks
references/verification.md
-- per-class post-edit verification recipes