Make Spring support an add-on library please! You can’t call something “minute” if it drags Spring and all its dependencies in

I enjoyed your KotlinConf talk by the way, and I’m a big fan of GOOS

@natpryce I'm thinking of moving the examples over to JUnitTests, but that is quite a commitment. How is it working for you?

Unit isn’t quite the same, because it says that you never have a fixture. You might want a fixture that in some tests is present and others absent. I know it was in the back of my mind when I made F : Any, but I can’t remember why I did that. Let me see if it’s still necessary.

gradlew is there but the wrapper jar it requires to bootstrap gradle is not

So it was just too hard to explain when to use JUnitTests and JUnitFixtureTests, so I've added a JupiterTests

object FirstMinutests : JupiterTests<Fixture>() {
    class Fixture { ... }
    override val tests = context {
        test("my first test") {

which keeps the annotation scariness hidden for both cases at the expense of another level of indentation.

Is there a practical difference between

modifyFixture

and

before

?

what is the purpose of test transforms?

I’d have to see it - it sounds like a lot of to-ing and fro-ing compared to the current straight through pipeline. I might be able to meet in town Tuesday morning or Wednesday evening - I’m out in Paris for the night.

@robfletcher are you using the JUnit rules support? @natpryce has done some sterling work to simplify the internals and remove reflection, but we haven't reimplemented the rules support yet.

I’m still a bit wary of the “magical underscore” convention. 🦄

i think people need to manually request an invite to this slack

@robfletcher you asked a long time ago about referencing the fixture as

it

. I've been playing and think that I can do this

data class Fruit(val name: String)
        data class Conserve(val type: String, val fruit: Fruit)

        junitTests<Fruit> {

            fixture {
                Fruit("blackcurrent")
            }

            derivedContext<Conserve>("inner") {

                deriveFixture {
                    assertEquals("blackcurrent", this.name)
                    assertEquals("blackcurrent", it.name)
                    assertEquals("blackcurrent", parentFixture.name)
                    // Doesn't compile
                    // assertEquals("blackcurrent", fixture.name)
                    Conserve("jam", parentFixture)
                }

                test("test") {
                    assertEquals("jam", this.type)
                    assertEquals("jam", it.type)
                    assertEquals("jam", fixture.type)
                    // Doesn't compile
                    // assertEquals("blackcurrent jam", parentFixture.fruit)
                }
            }
        }

@robfletcher @natpryce @christophsturm It would be good to get together for a chat about the API direction. Maybe 30 minutes of screenshare to put forward some options - we have prototypes of 2 designs. Is there a time today when we're all sitting at a computer and free? I could make pretty much any time before 2300 UTC with a bit of notice

Also… is there any way to prevent calling context builder functions from within tests? The Dsl Marker mechanism doesn’t seem to work. Or at least, doesn’t work the way I expected it to.

That is cool.

Context<PathTemplate<T>, PathTemplate<T>>

->

TestContext<PathTemplate<T>>

- it's a shame that IntelliJ doesn't offer the most specific type alias in these cases

Make sure that your runner supports that 😉

The val feels pure, but at the expense of being evaluated at an indeterminate time. The fun gives us control over reporting errors

Also visibility

If

TestDescriptor

is actually a

TestExecution

, then it can register resources that need to be cleaned up at the end of the test run…

Which brings me back to a question I had earlier... should RuntimeContext have methods for creating a copy with different children? That’s what PlainContext allows. Should there be a published API call to make that easier?

But the engine could find transforms to apply when it scans the classpath

thats much better

Version 0.36.0 fixes a bug in the JUnit 4 runner and stops publishing a dependency on JUnit 4 and the classgraph jar required by the minutesttestrunner. Ideally I'd mark these are provided, but haven't found a way to do that yet. /@christophsturm

Anything else?

One downside is that IntelliJ marks the method returning the

RootContextBuilder

as unused because you’re finding it with reflection-y magic

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

Welcome @DP-TKS - please let us know how you get on

I like that that is an option, but dislike the knowledge that we’re repeating the same setup code just to make multiple asserts read well.

i treat all code comments as bugs