I think you should first decide what you want the final code to look like, before planning the incremental steps to get there.
However, are you sure really want to change everything to interfaces - purely to facilitate mocking, and for no other good architectural reason? It doesn't sound right to me, but the "Dog" example is too abstract to know what you're really trying to achieve here. You have a function that takes and/or manipulates a Dog, but the behaviour at test time can't be satisfied by a real Dog. Why is that? Is it because the Dog depends on some other object? Maybe *that's* what needs mocking. Maybe you do want an interface here to represent the behaviour that you're mocking. But your comment talked about "adding a function that needs not be mocked anywhere, or a field that could a priori simply be accessed as is". Surely those things would be private implementation details of a Dog, and not part of the interface? Equally, if users of Dog are directly accessing fields, then they are tightly bound to the implementation of Dog anyway. Maybe the behaviour you're talking about belongs outside of Dog altogether, like in a DogHandler object (which could have different implementations for Dog and FakeDog). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/07ddff7a-48e4-48fa-abe5-9683912e47aen%40googlegroups.com.
