How Testability Drives Observability
summary
Argues that using real trace data as test assertions catches gaps ordinary end-to-end tests miss, and creates a feedback loop that forces better telemetry. Uses trace-based testing with the open-source MIT-licensed Trace Test (UI + CLI) against a Pokemon API demo backed by Postgres, RabbitMQ and pokeapi. Demonstrates assertions for HTTP status 200, span duration <1s, and attribute pokemon.id = 25, fixes instrumentation to satisfy the failing test, and reruns until tests pass.
AI-written summary · about
chapters (10)
- 0:00Start
- 0:27What is observability?
- 1:03What is distributed tracing?
- 3:41Typical instrumentation lifecycle
- 5:41Observability is hard
- 7:57What is Trace-based testing
- 8:13Trace-based testing: compared to an e2e test
- 13:08Advantages of trace-based testing
- 20:46Trace-based testing demo
- 35:08Tracetest community
related talks
36mHow Testability Drives Observability
39mHow Testability Drives Observability
16mBreaking the Chain of Blame: How to Get True Test Observability?
24mWhat is observability-driven development?
43mObservability-Driven Development with Kubernetes
21mThe Road to Observability Everywhere at Monday.Com
33mThe Observant Developer - OpenTelemetry from code to prod
37mObservability-Driven Development