Support for testing against Datadog instance

[sampengilly]

Feature description

I'm working on code that integrates with Datadog android APIs that I'd like to test effectively without relying on heavyweight mocks for Datadog objects and functionality.

For example, for internal use in my organisation I have a wrapper library which assists with configuring Datadog correctly across a handful of different apps. I also have an Otel LoggerProvider implementation which routes logs to the Datadog logger. I'd like to be able to write tests that can verify the correct interactions with the Datadog API such as verifying that specific features are enabled and inspecting their config, or capturing the log entries received and processed by Datadog.

At the moment many of the elements of the SDK are accessed via separate static objects and builder functions around an SdkCore instance. I haven't seen anything in the docs or code which looks like a publicly available set of testing utilities which could be used to avoid lots of mocking of the public parts of the Datadog SDK.

Proposed solution

I'd expose a testing library containing a TestRule for managing a Datadog instance during tests, along with a collection of Fakes for different features and the SDK core.

Other relevant information

No response

[aleksandr-gringauz]

Hello, @sampengilly!

Thank you very much for your feature request.

I haven't seen anything in the docs or code which looks like a publicly available set of testing utilities which could be used to avoid lots of mocking of the public parts of the Datadog SDK.

Indeed, we currently don't provide any public testing utilities that would help you test your code against DataDog SDK. We have this stub that we use for our internal testing purposes, you may have a look at it for inspiration. However it isn't directly usable by clients of the SDK.

I'd like to be able to write tests that can verify the correct interactions with the Datadog API such as verifying that specific features are enabled and inspecting their config, or capturing the log entries received and processed by Datadog.

At the moment many of the elements of the SDK are accessed via separate static objects and builder functions around an SdkCore instance.

Could you describe a specific testing scenario that you currently have trouble implementing? Maybe we will be able to assist somehow.

[sampengilly]

One example scenario is that I've written an Otel logging wrapper similar to the OtelTracerProvider that is included in the Datadog SDK.

I'm writing tests to ensure that when I log via an Otel logger, it correctly results in the Datadog Logs feature receiving a matching log. This would also be useful for end-to-end testing things like a logs attribute mapper to help convert some Otel semantics to Datadog equivalents (e.g. exception.type to error.type).

Another example is that I have a helper class that initialises the Datadog SDK consistently across a handful of apps, it would be good to have a test rule that would allow me to inspect the initialised SdkCore to determine what configuration options it's using. I'm mostly able to work around this right now, but I do need to depend a little bit on an internal API to do so.

[aleksandr-gringauz]

@sampengilly Thank you for a detailed explanation!

I understand what you try to do, I'm afraid currently there isn't a solution better than what you currently have.

We will discuss your request internally.