Propagate mock baggage items about opentracing-java

[yurishkuro]

I have used mock tracer on a number of occasions to verify that some instrumentation is done correctly. However, I never needed to also verify that baggage is propagated. Could you describe the use case when it is needed? The mock tracer is not supposed to be used in real scenarios.

[bhanafee]

Understood about proper use of the mock tracer. The only "real scenario" here is a real unit test.

My use case requires a specialized carrier. It is agnostic about the tracer implementation and uses the conventional Java API for Tracer, Span and SpanContext. It communicates with the Tracer via a wrapper that makes the specialized carrier look like a simple TEXT_MAP, using inject and extract to pass the SpanContext back and forth. That part works just fine for mock span and trace IDs.

Some of the unit tests for the carrier wrapper explicitly include baggage items. They should make the round trip alongside the span and trace IDs to carrier and back via inject and extract functions supplied by the (in this case mock) Tracer.

In more detail, the test is:

• Use mock tracer to start a parent span
• Add a few baggage items
• inject a SpanContext representation into the specialized carrier
• extract the SpanContext from the specialized carrier
• Check trace and span IDs were transmitted via the carrier (passes)
• Check the baggage items were transmitted too (fails)

In other words, I need mock baggage items to test whether my own carrier code handles baggage items correctly. Took me a little while to figure out why it kept failing.

[bhanafee]

I did send a PR for the enhancement. The code itself and corresponding test case might clarify more than my prose explanation. All it does is

• Add all the baggage items to the Map before adding the span and trace ids (so baggage items can't interfere with trace or span)
• Extract items that aren't the span or trace into baggage items

The PR should be backward compatible. It doesn't interfere with existing mock span or trace id, and existing tests presumably wouldn't include baggage items since they don't work.

[yurishkuro]

Unless setting & reading the baggage is somehow critical to the behavior of your solution, it seems like it's redundant to test if your protocol is correctly propagating the baggage given that you already confirm it's propagating the span context - it looks more like you're testing the tracer implementation rather than your own code.

But I don't have objections to the PR itself.

[bhanafee]

It's critical that my carrier implementation carry the baggage items because it's part of the API for a SpanContext. You may well be correct that the test is at least partly redundant, and I could have tested my carrier more directly. The fact that the test passed immediately when I patched the MockTracer would tend to support that view. Adding baggage handling to MockTracer certainly made my unit tests more readable and understandable, and seems more generally useful.

[bhanafee]

Closed by PR#129