4 ms·
So you just copy and paste the subsets of the Backend methods and their signature into separate interfaces that only have the methods needed for the user functi
by lxe 7y ago
So you just copy and paste the subsets of the Backend methods and their signature into separate interfaces that only have the methods needed for the user function and its test? That doesn't sounds very good.
I'd rather have one global "backend" interface and have mocks use that. If the type system gives me issues with unimplemented methods, than that's the problem with the type system itself -- allowing for partial interfaces (through keywords or something) should be a first-class feature.
- y2bd 7y agoCan’t speak for Go, but TS does provide the `Pick<T, K>` construct, essentially meaning “from a type T, I only require a subset of properties K”. This avoids needing to duplicate partials of the core interface. It does now strongly couple you to the core interface—you can’t put this function in a separate module that’s unaware of the core interface anymore—and now if the core interface changes, the function implementation itself will break instead of the call sites (which could be a good or a bad thing).
- sagichmal 7y agoIf I take a complete Backend but only use 1 of 10 methods, that relationship is better expressed as an interface with that single method. Constraining the possible behavior of that code via this kind of contract makes it easier to understand (the signature says more by permitting less) and test (the interface provides a natural mock point).
- jayd16 7y ago>through keywords or something The whole point is to avoid this. Currently in many languages you could trivially generate method stubs that throw errors or some such thing but that still slows down iteration and opts you into far more baggage than necessary.