Readme should explain how to test statsd code
grosser opened this issue · 3 comments
client.Timing("external_request", time.Since(start), tags, 1)
... now how do I write a test to assert this has been called ?
+1 on this. I think a lot of the challenges here are a function of the push model (as opposed to a pull model. I don't think we have a push telemetry options (do we?), so we'll need to do what we can.
In my particular case, I had to add a --datadog-dogstatsd-disable, which uses NoOpClient instead of Client, just to allow tests to run on developer machines or on CI...
We're still stuck with the question "how can test whether my app is exporting the metrics I expect it to be?". I see 2 options:
- Deploy DogStatsD locally, wherever tests need to be ran, and assuming DogStatsD has some interface to read the state of metrics, we can assert on that.
- Implement a "test variant" of
ClientInterface, which contains extra methods to enable us to query the value of metrics, and thus be able to assert on those.
The former is possible, but impractical on the general case. The latter seems reasonable, but the size of ClientInterface means it'll require a fair bit of code. IMHO, the latter is the way to go here.
You could always generate a mock for ClientInterface using something like Uber mock and pass the mock to your function that calls the DogStatsD client.
Hum... I reckon this would be possible, but I think this makes testing cumbersome, as not only users have to jump through extra hoops to setup things, it'd require a fair bit of boilerplate code, which may not be shareable across each test.
From a naive high-level end-user perspective, I'd be interested on, ideally:
- Running the code, let it generate as much telemetry as it wants.
- Assert on the state of specific telemetry values on Datadog.
for (2), we'd require a mocked Client that keeps in memory the value of the received telemetry, "pretending to be" the statsd. This mock could have some extra methods to enable assertion on specific telemetries. In this model, testing setup + assertion would only require a few lines of code (and this is roughly how it works for Prometheus :-D).
WDYT @carlosroman ?