Thanks Brian for your answer. Indeed it is hard to convey the whole problem with just a metaphor... But your suggestion that maybe mocking the "contained" parts would work is helpful here. So if the Dog does not itself interact directly with critical systems (DB, git...) then we could provide a Dog that does exactly what it's supposed to do, just that some things it will do are mocked under the hood.
For the last part of your answer, I did not express myself clearly about the fields and methods of Dog that don't belong in the interface. Here there would be a method "Bone" in the interface "DogOperator" to retrieve the bone, only because the (exported) field is hidden behind the interface itself, which I find quite ugly to be honest. The final state I would like is to have functions using a Dog everywhere with helpers taking (correctly designed) interfaces for particular behaviors eventually. So the functions using the Dog would use the Dog directly and send it to functions taking a DogOperator for factorable parts, that can be represented by the method set of those interfaces. Le mar. 19 oct. 2021 à 15:07, Brian Candler <b.cand...@pobox.com> a écrit : > 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 golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/07ddff7a-48e4-48fa-abe5-9683912e47aen%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/07ddff7a-48e4-48fa-abe5-9683912e47aen%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAL4P9zwRKjK35xMj%2BSmoFCH4Q4G9O6bZ1GjvbB1wDatd-Vw63w%40mail.gmail.com.
