I hate this pattern. Needless indirection for insignificant benefit.

It's indeed horrible when debugging. OTOH, there's merit to the idea that better testing means less overall time spent (on either testing or debugging), so design choices that make testing easier provide a gain -- provided that good tests are actually implemented.

Golang "punishes" you for wanting to write a unit test around code.

You need to refactor it to use an interface just to unit test it.

No, you don’t, unless you’re of the opinion that actual data structures with test data should not be used in a unit test.

I think you're missing the point here.

Duck typing with python (e.g.) makes it easy to mock a class. One can subclass a Java class to make a mock, etc.

One can't do that in golang unless it's through an interface which then decouples tightly coupled code because [golang reasons].

> But don't those exist primarily for unit testing?

I believe that's why people insert them everywhere, yes, but in the codebases I'm talking about, many (I'd say the majority, to be honest) of the interfaces aren't used for testing because they've just been cargo-culted rather than actually considered.

(Obviously this is with hindsight - they may well have been considered at the time but the end result doesn't reflect that.)