<@U0E2MNCPN> going back to our discussion about ho...

# minutest

[robfletcher]

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

[dmcg]

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

[robfletcher]

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

[dmcg]

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,

[dmcg]

Oh, no, they aren't

[dmcg]

and that's the problem really

[dmcg]

because the Fixture isn't buying you anything in expressibility

[dmcg]

Even if the repositories and mocks are too expensive to keep creating, in this case I think that I'd reference them in the fixture

[dmcg]

make the fixture Closable and have it reset them on close

[dmcg]

BTW I'm nervous about object - because JUnit 5 seems to create another instance of your type anyway.

[dmcg]

So the when in your tests is validateManagedResources() ?

[dmcg]

If so, then I'd be inclined to refactor to something like https://gist.github.com/dmcg/29f7ff02913fc9756952aea611b721f3

[dmcg]

This way the fixture class earns its keep in allowing the tests to express just what you need to know.

[robfletcher]

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.

[dmcg]

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

[dmcg]

(Actually if an after throws I stop running them, because they take the fixture)

[robfletcher]

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

[dmcg]

Ah no, I don't automagically close (it's on the idea's list though). There is an after { fixture.close() } in the Gist

[dmcg]

There is an experimental Auto-close, but it works with lexical rather then Fixture scope, and I'm going off it.

[robfletcher]

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

[dmcg]

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

[dmcg]

Did you see the Gist I posted @robfletcher ? That’s my current thinking on the sort of scope a fixture should have

[robfletcher]

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