What's the problem? Testing large systems and multiple microservices is hard to understand. Such a big system can quickly become convoluted. You need to be a specialist in that area to understand the whole system, all connections, and how the microservices interconnect.

How do we solve it? With tracing you get a map of everything which makes your whole system easier to understand. I want to showcase traditional test-driven development vs the new observability-driven development with Tracetest and OpenTelemetry. With observability-driven development, you can improve your traces by using trace-based testing to enrich integration tests. No more black boxes when running integration tests. You'll know exactly what's happening in each microservice. You'll also be able to add test specs and assertions for every step the transaction takes through your distributed system!

What's our production use case? Test-driven development is your thing. But, you’re using OpenTelemetry for traces? You have everything you need to move to observability-driven development. It will leverage your OpenTelemetry traces to create integration tests with more details and precision than ever before.

We call it trace-based testing. It’s becoming popular to test systems at an integration or end-to-end level by applying assertions against the data contained in an OpenTelemetry trace. 

These tests can check your code, they can verify your trace info is added correctly and can verify processes that show up deep in the trace worked as expected.

We’re building an open-source tool called Tracetest (https://github.com/kubeshop/tracetest) to make observability-driven development mainstream. It leverages the observability enabled by OpenTelemetry traces to allow you to create trace-based tests. These tests can check your code, they can verify your trace info is added correctly and can verify processes that show up deep in the trace worked as expected.