Observability
Sentry integration is easy to break silently—a wrong DSN, a muted beforeSend hook, or a missing SDK init call can cause errors to vanish without anyone noticing. This guide covers how to verify Sentry actually captures what it should: SDK mocks in unit tests, integration tests for captureException, testing
Observability
Prometheus alerting rules can fail silently for years: a typo in a PromQL expression, a label mismatch in Alertmanager routing, or a threshold that never actually fires. promtool provides a native unit testing framework for alert rules—YAML-defined tests that validate expressions against synthetic time-series data without running a live
Observability
OpenTelemetry instrumentation can silently break—spans stop being created, attributes go missing, or trace context fails to propagate across service boundaries. The OTel SDK ships with an InMemorySpanExporter specifically for testing: it captures spans in memory so you can assert their structure without running a collector. Key Takeaways InMemorySpanExporter is
Observability
Logs are observable outputs of your system. Like return values and HTTP responses, log output can be tested—and should be. This guide covers structured log assertions in integration tests, capturing logs in Python and Java, testing log level and context fields, asserting no unexpected errors appear during a test
Observability
Datadog is not just a dashboard—it's a test surface. This guide covers asserting APM trace structure in tests, using Datadog Synthetics as CI quality gates, enforcing p99 latency thresholds before deployment, and mocking the Datadog agent so unit tests stay fast and isolated. Key Takeaways APM traces
Testing
Grafana Tempo is a cost-efficient, horizontally scalable trace backend built for the Grafana observability stack. It works well as a test-environment trace store because it's simpler to configure than Jaeger with external storage, integrates naturally with Prometheus and Loki, and supports TraceQL — a purpose-built query language for traces.
Testing
Tracing tells you what happened — testing tells you whether it should have happened. OpenTelemetry brings them together: instrument once, verify always. What OpenTelemetry Adds to Testing Classic unit and integration tests check return values. They miss latency, span counts, attribute correctness, and propagation across services. OpenTelemetry testing fills that gap
Testing
The idea: if your system emits traces and metrics in production, those same signals can power your tests in development. Observability-driven testing (ODT) treats telemetry data as first-class test assertions. The Problem with Classic Integration Tests A typical integration test: test('order placement succeeds', async () => { const res
Testing
Jaeger is CNCF's open-source distributed tracing platform. It stores, indexes, and visualizes traces — and its REST API makes it a natural assertion target for integration tests. This tutorial walks from zero to running trace assertions. Why Jaeger for Testing Jaeger is popular in test environments because: * Single-binary all-in-one
Testing
When you're adding distributed tracing to your test environment, Zipkin and Jaeger are the two open-source tools you'll evaluate. Both capture traces. Both work with OpenTelemetry. The differences matter when you're writing test assertions and running traces in CI. Quick Comparison Feature Zipkin Jaeger
Testing
A unit test tells you a function works in isolation. A distributed trace tells you whether it worked as part of a real request flowing through ten services. These two views are complements, not replacements — and modern testing stacks need both. Why Distributed Tracing Changes Testing In a monolith, a