This pattern violates DRY the hard way. I think most seen example is Go, where stdlib has no "http.Client" interface but only a struct.
So every implementation of http client at some point gets the same copy-pasted code for the interface, so it could use it for that pattern of mocking. I'm not saying it's bad - I'm also doing it. It's just a design decision.
If that interface was in the http package, that would be a problem. Let's say they want to add a new method to http.Client . Would they add that to the interface? If no, then it would be difficult to test code that uses that new method. If yes, then all existing mocking code will stop compiling, because those mocks will no longer implement that interface.
This pattern violates DRY the hard way. I think most seen example is Go, where stdlib has no "http.Client" interface but only a struct.
So every implementation of http client at some point gets the same copy-pasted code for the interface, so it could use it for that pattern of mocking. I'm not saying it's bad - I'm also doing it. It's just a design decision.