3 ms·

This seems like an is-ought fallacy. What you're describing is not a "you shouldn't," it's a "you can't due to limitations in the language."

• ollien 4y ago
  TIL about that fallacy. That's a fair point. I guess it comes in a bit differently in C++ land, because the "you shouldn't" comes into what you decide to allow to be injectable (e.g. if your constructor only accepts the third party object type, you're not gonna be able to mock it). As such, you gotta keep the principle in mind when designing your objects. That said, you're definitely right, it smells like that fallacy
  • nijave 4y ago
    I think that applies to other languages, too. There doesn't tend to be much (any?) magic mocking in Go but more "real" local HTTP servers to stub responses and duck typed fake implementations On the other hand, in Ruby and Python it's pretty trivial to monkey patch and magic mock
    • ollien 4y ago
      Go is a good example, too. Unlike C++ though, the distinction between something with dynamic dispatch (an interface) is a bit more explicit than in C++ (a class with virtual methods, which may not all be virtual). That said, in your example, yeah: if you just pass a stock http.Client around, you lose any ability to mock that short of spinning up a dummy webserver.