How to use `DatadogCoreProxy` in tests?

What is DatadogCoreProxy?

In #1111 we introduced DatadogCoreProxy utility. Unlike DatadogCoreMock which it replaced, the proxy relies on the real DatadogCore when facilitating tests. When depending on DatadogCoreProxy in test, we maximise the coverage of actual core logic, including real queues, threading and features initialization routines.

Why using DatadogCoreProxy?

• Replacing previous mock with DatadogCoreProxy revealed several actual issues in SDK, mostly solved in #1123.
• Because proxy depends on real DatadogCore, all changes made to the heart of SDK automatically get effective in tests.
• It doesn't require maintaining separate core implementation only for tests (which is flaky, as we lear from #1123)

When to use DatadogCoreProxy?

The rule of thumb could be:

Each time when your test logic is fragile to threading details in DatadogContext propagation or messages exchange on event-bus.

In practise this could be narrowed to:

• high-level tests for the core module;
• integration unit tests for modules communication between V1 Features.

How to use DatadogCoreProxy?

The minimal example in V1 this:

let core = DatadogCoreProxy(context: .mockWith(service: "foo-bar"))
defer { core.flushAndTearDown() }
core.register(feature: LoggingFeature.mockAny())

let logger = Logger.builder.build(in: core)
logger.debug("message")

let events = core.waitAndReturnEvents(of: LoggingFeature.self, ofType: LogEvent.self)
XCTAssertEqual(events[0].serviceName, "foo-bar")

Note: the core.flushAndTearDown() must be uniformly called after each test, otherwise tests integrity check will report a leak on the core instance.