4 ms·

It depends on your language and testing framework. In C++-land, for instance, you can't mock a third party library if they don't define virtual methods, forcing

• int_19h 4y ago
  If you are mocking the library in its entirety, you just define the same classes/functions that they do - virtual or not - and then link to your implementation instead of theirs for the test build.
  • ollien 4y ago
    Heh, that's an interesting strategy. My company primarily works with gmock, and I'm not certain you could do what you describe with gmock, but yeah that would work otherwise.
• chc 4y ago
  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.