Remove dependency on prometheus/tsdb

[beorn7]

This repo has a dependency on prometheus/tsdb solely for using the github.com/prometheus/tsdb/testutil package.

Using testutil packages is a disputed practice in the Go community. I'd like to avoid it if we can in a widely used library like this one.

If we really have to use a Prometheus-owned testutil package, it should live in prometheus/common. (The fact that it doesn't live there probably implies that this package was never meant to be used outside of prometheus/tsdb.)

For some context, see https://github.com/prometheus/client_golang/pull/570/files#r286247680 .

[beorn7]

WRT to cognitive overhead of a testutil-like package:

I have claimed that it increases the cognitive overhead. However, @krasi-georgiev notes in #570 (comment) that he believes it “simplifies the code without any cognitive overhead”. He asks: “What do you think about adding the testutils in the common repo?”

To explain my point of view (which is not really my very own point of view, it's more like what I believe the hive mind of the Go community thinks): Looking at the functions in github.com/prometheus/tsdb/testutil/testutil.go, they are mostly concerned with a particular stylized output. While the output looks nice, it's problematic to assume it will work well for the general case. (The litmus test here is: If it is generally really useful, why is it not part of the standard testing package?) A secondary effect is the code simplification it provides, i.e. even if we don't want or need the pretty output, Assert, Ok, Equals etc. usually allow somewhat shorter code. I would dispute that “shorter” equals “simpler” in this case. (Again the litmus test here is to look at the standard testing package: If idiomatically written Go tests should have those shorteners, why aren't they in the standard testing package? They are fairly trivial to implement, so the Go authors have certainly thought about it.) Even if we would settle on the lack of features in the standard testing package being a mistake, a code reader from a different context will be confronted with the problem that they run into many slightly different testutil-like packages (because many have written those). If a test fails in a non-obvious way, the reader will look at the test code and then have to think about what exactly that helper function is doing. That's a cognitive overhead as there is no standard for those helpers.

To turn prometheus/tsdb/testutil into prometheus/common/testutil, we needed agreement that all (or most) of the Prometheus project should use this kind of stylized printing. That's a valid proposition, but I'd personally err on the side of simplicity and not add complexity for a mostly cosmetic reward.

Even if we had that in prometheus/common, I'd still argue that the client library are somewhat special as they are the code that is most often used and read by programmers that are not usually coding for Prometheus project. I'm reluctant to draw them into an opinionated way of writing tests and formatting their output and would rather stick as closely as possible to vanilla Go, even if it is a bit more verbose and the output uglier.

[brian-brazil]

I'd still argue that the client library are somewhat special as they are the code that is most often used and read by programmers that are not usually coding for Prometheus project.

👍