https://kotlinlang.org logo
#minutest
Title
# minutest
r

robfletcher

02/16/2019, 4:08 PM
@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.
d

dmcg

02/16/2019, 4:21 PM
I prefer the second, but might stoop to the first if the mock creation is unacceptably slow.
r

robfletcher

02/16/2019, 4:22 PM
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
d

dmcg

02/16/2019, 4:23 PM
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,
Oh, no, they aren't
and that's the problem really
because the Fixture isn't buying you anything in expressibility
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
make the fixture Closable and have it reset them on close
BTW I'm nervous about
object
- because JUnit 5 seems to create another instance of your type anyway.
So the
when
in your tests is
validateManagedResources()
?
If so, then I'd be inclined to refactor to something like https://gist.github.com/dmcg/29f7ff02913fc9756952aea611b721f3
This way the fixture class earns its keep in allowing the tests to express just what you need to know.
r

robfletcher

02/16/2019, 5:00 PM
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.
d

dmcg

02/16/2019, 5:04 PM
`after`s are run backwards, so it should be safe provided that you dispose at the same level as you create for every resouce
(Actually if an after throws I stop running them, because they take the fixture)
r

robfletcher

02/16/2019, 5:07 PM
Right so minutest will track the level at which the fixture was created and close it at that same level?
d

dmcg

02/16/2019, 5:08 PM
Ah no, I don't automagically close (it's on the idea's list though). There is an
after { fixture.close() }
in the Gist
There is an experimental Auto-close, but it works with lexical rather then Fixture scope, and I'm going off it.
r

robfletcher

02/16/2019, 5:12 PM
Oh I see you’re suggesting I call close myself in the after block
d

dmcg

02/16/2019, 5:13 PM
Only because you have resources that aren't being discarded by the creation of the new fixture when the fixture is discarded
Did you see the Gist I posted @robfletcher ? That’s my current thinking on the sort of scope a fixture should have
r

robfletcher

02/17/2019, 9:58 PM
I did. I’m mulling how I feel about it. Going to have a play tomorrow.
👍 1
4 Views