@dmcg going back to our discussion about how to appropriately define fixtures, I’ve dug out a couple of examples from the codebase I’m currently working on. 1. in this case I’m just using the CUT as the fixture and other fields are class level fields: https://github.com/spinnaker/keel/blob/master/keel-plugin/src/test/kotlin/com/netflix/spinnaker/keel/plugin/monitoring/ResourceStateMonitorTests.kt 2. here’s one where I’m putting everything in a fixture object: https://github.com/spinnaker/keel/blob/master/keel-ec2-plugin/src/test/kotlin/com/netflix/spinnaker/keel/api/ec2/SecurityGroupRuleTests.kt In neither case am I very comfortable with what I’m doing.

I prefer the second, but might stoop to the first if the mock creation is unacceptably slow.

I lean that way as well, but I’m too lazy to keep writing fixture classes. It also gets messy when mixing this with derivedContext where there might be > 1 fixture type

In the first case I don't think that I'd have the

before

blocks - they are just mutating the fixture, so make them fixture blocks,

What are the implications of using closeable if you have nested contexts? e.g. fixture created at higher context with multiple nested ones to group before steps.

`after`s are run backwards, so it should be safe provided that you dispose at the same level as you create for every resouce

Right so minutest will track the level at which the fixture was created and close it at that same level?

Ah no, I don't automagically close (it's on the idea's list though). There is an

after { fixture.close() }

in the Gist

Oh I see you’re suggesting I call close myself in the after block

Only because you have resources that aren't being discarded by the creation of the new fixture when the fixture is discarded

I did. I’m mulling how I feel about it. Going to have a play tomorrow.