3 ms·
> people start using that abstraction pattern before there's actually multiple potential concrete implementations But that's what I mean: the second concrete i
by skohan 6y ago
> people start using that abstraction pattern before there's actually multiple potential concrete implementations
But that's what I mean: the second concrete implementation is the mock which has been created for unit testing, and this is how unit testing introduces complexity and indirection.
- treis 6y agoThis is a place where Go's duck typing really shines. You can create a mock class without having to modify the actual code.
- RangerScience 6y agoHmm. So what I'm doing is that I have a wrapper object with a private member variable that's the client from the service's API library (for this example, it's DialogueFlow). My wrapper then has a function for each basic thing that my code actually wants to do with the library, translating from the plain data objects (or straight arguments) that're in use in the rest of my codebase into the nested object mess that DF talks in (and back again, when there's return values). Then in tests, I just monkeypatch the private `client` method/variable to return/be the mock. The mock then replicates only the functionality that I actually use from the service's library, which is easy to do since there's only one file to look at for all usage. I now have my own DSL for interacting with the service, and I understand the service well enough to fake it, which has been super helpful. So far I'm loving it, and it doesn't feel at all like the "where's the !#$%! bean" hell of Spring.