// the take
Tracetest lets you write integration and e2e tests that assert against OpenTelemetry trace data instead of just HTTP responses — so you can check things like "the database span took under 50ms" or "all gRPC calls returned status 0" directly against your real instrumentation. It's aimed at teams already running distributed tracing (Jaeger, Tempo, OpenSearch, etc.) who want test assertions that reach into the actual trace rather than mocking service boundaries.
The selector language for targeting spans (span[tracetest.span.type="database"]) is a genuinely useful idea — it turns trace data into something you can write real test logic against instead of eyeballing a waterfall diagram. Tests are plain YAML, so they're diffable and CI/GitOps-friendly, not locked in a UI. It plugs into whatever trace backend you already run via the OTel Collector pipeline rather than forcing a new one, and the CLI covers the full loop (run, import, export) for actual pipeline use, not just local demos.
The open-source "Core" tier is explicitly called out as not production-ready — self-hosted production use pushes you toward the paid Enterprise license or their cloud, which limits how far you can take this for free. Assertions depend entirely on span attribute names and structure being stable across your tracing setup; any instrumentation drift silently breaks tests rather than failing loudly. It's also a second test system to maintain alongside your existing HTTP/unit test suite, and debugging a failing trace-based assertion means understanding both the selector syntax and your service's actual span topology, which is a real learning curve for a team that doesn't already read traces regularly.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →