There 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.

You've just restated your original comment, without addressing the fact that this does not work with the third example in my original comment.

How so? You can mock any of bar/baz/quux however you want using the patterns/techniques above. Am I misunderstanding something?

Again, 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.

Ah, 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).

It'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-l...) if you're curious

I thought you were looking for ways to DRY up creation of a set of mocks?

I 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.