3 ms·
But that's because you're doing continuation passing style. You could do this instead: func make_foo() *Foo { return &Foo { bar: make_bar(),
by lhorie 5y ago
But that's because you're doing continuation passing style. You could do this instead:
func make_foo() *Foo {
return &Foo {
bar: make_bar(),
baz: make_baz(),
quux: make_quux(),
}
}
func cleanup_foo(foo *Foo) {
cleanup_bar(foo.bar)
cleanup_baz(foo.baz)
cleanup_quux(foo.quux)
}
// elsewhere
foo := make_foo()
defer cleanup_foo(foo)
// [rest of logic goes here]
- Arnavion 5y agoPlease see the third example I gave, which talks about the set of mocks not being the same for every test.
- lhorie 5y agoThere are several options Poor man's: func make_foo_with_mock_bar() *Foo { return &Foo { bar: make_mock_bar(), baz: make_baz(), quux: make_quux(), } } Explicit injection: func make_foo(bar: Bar, baz: Baz, quux: Quux) *Foo { return &Foo { bar: bar, baz: baz, quux: quux, } } Or use some DI framework Even if you have reservations about where verbosity lies, I don't see how this affects the cleanup side.
- Arnavion 5y agoYou've just restated your original comment, without addressing the fact that this does not work with the third example in my original comment.
- lhorie 5y agoHow so? You can mock any of bar/baz/quux however you want using the patterns/techniques above. Am I misunderstanding something?
- Arnavion 5y agoAgain, your Foo always contains a bar, baz and a quux. And again, the third example in my original post talks about how not every test needs all three.
- lhorie 5y agoAh, I understand now. My understanding is that with zig and go, one does not DRY deferring, it's just a part of the idiom trade-offs between verbosity and explicitness. So if bar, baz, quux aren't intrinsically related as a unit and might be mixed and matched arbitrarily, you just forego the whole ceremony and call each thing or the respective mock individually (the argument being that if you're making multiple different permutations, you're not repeating yourself per se; e.g. mocks don't need to be cleaned up in the first place) There's also something to be said about tests needing several arbitrary mocks. Normally, I'd consider that a smell. I've actually seen the pattern of making a kitchen sink foo for scenarios like that, but with nils/noops for unused things (can't say I like that approach though).
- dnautics 5y agoIt's a huge code smell. It's funny because just today I was listening to a podcast about testing and they talk about exactly these sorts of contrivances as being a good sign you should not be mocking something in a test. (https://smartlogic.io/podcast/elixir-wizards/s6e6-matthias-leopardi/ https://smartlogic.io/podcast/elixir-wizards/s6e6-matthias-l...) if you're curious
- AlexCoventry 5y agoI thought you were looking for ways to DRY up creation of a set of mocks?
- Arnavion 5y agoI am. With the three mocks I gave, there are 2^3 - 1 = 7 possibilities of which mocks a particular test needs. Of these, three are degenerate cases of a single mock each which would be served by the individual make_* already, so that leaves four cases of make_foo* that you'd need to implement. With more than three mocks, this number grows rapidly.