Install Tracetest CLI (tracetest) and deploy the Tracetest server, connecting it to your existing trace backend (Jaeger, Tempo, or an OTLP-compatible store) via the tracetest configure command
Create a test definition YAML file with a trigger section (HTTP request details) and a specs section containing span selectors and assertions
Write span selectors using the Selector Language, e.g., span[tracetest.span.type='http' name='POST /orders'] to target specific spans by type, name, or attribute
Add assertions under each selector, such as attr:http.status_code = 200 or attr:tracetest.span.duration <= 500ms, to validate both correctness and performance
Run the test with tracetest run test -f my-test.yaml; Tracetest triggers the request, waits for the trace, and evaluates all assertions, reporting pass/fail per span
Integrate into CI by adding tracetest run test to your pipeline; use --output junit to produce JUnit XML results compatible with most CI reporting tools
Known gotchas
Tracetest needs the complete trace to be available before evaluating assertions; if your trace store has high ingestion lag, increase the pollingProfile wait time in the Tracetest config to avoid premature evaluation
Selectors match spans by attribute value; if your instrumentation does not set the expected semantic convention attributes (e.g., http.method, db.system), selectors will match zero spans and tests will fail or vacuously pass
Tracetest replays the trigger on each test run, so tests that mutate state (e.g., POST /orders) will create real side effects in your system; use a test environment or idempotency mechanisms
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp