,
8 tweets,
2 min read
Read on Twitter
One neat trick for testing is to test the output of telemetry data.
This is way more low touch than trying to refactor code to make it “testable”.
Many a time, this leads to awkward APIs, encapsulation violations and more.
This is way more low touch than trying to refactor code to make it “testable”.
Many a time, this leads to awkward APIs, encapsulation violations and more.
First, it makes you treat things like loggers, tracers and metrics sinks as dependencies. No more shared global state.
Every test instantiates it’s own logger and passes it to the code being tested. The code will do its thing and 1) result a result or an error 2) emit telemetry.
Every test instantiates it’s own logger and passes it to the code being tested. The code will do its thing and 1) result a result or an error 2) emit telemetry.
Second, this enables more airtight encapsulation. You don’t need to make methods/properties public just because you want to test something.
Just check the telemetry output instead. You can maintain clean public APIs that expose just enough to the clients.
Just check the telemetry output instead. You can maintain clean public APIs that expose just enough to the clients.
Third, it makes sure you add instrumentation to important parts of your code. You can verify that the code functions correctly, and more importantly, that the instrumentation is correct!
Super helpful when debugging to have confidence that the data you’re looking at is correct.
Super helpful when debugging to have confidence that the data you’re looking at is correct.
Fourth, passing a context around (even within a single process) allows for testing the latency of various components of code across a wide variety of inputs.
More focused “local stress testing” can help shake out a number of bugs in the hot/critical path of the codebase.
More focused “local stress testing” can help shake out a number of bugs in the hot/critical path of the codebase.
And all of this can just look like unit tests!
It can run as a part of your test harness in CI, without having to make a ton of investment in setting up an integration testing infrastructure.
It can run as a part of your test harness in CI, without having to make a ton of investment in setting up an integration testing infrastructure.
This isn’t comprehensive by any means, and there are many other forms of testing we should be pursuing.
But purely in terms of testing code functionality, more than small functions to make code “unit testable”, instrumentation APIs can be leveraged a lot more and a lot better.
But purely in terms of testing code functionality, more than small functions to make code “unit testable”, instrumentation APIs can be leveraged a lot more and a lot better.
h/t @peterbourgon for tweeting about the same earlier.
