@hhariri: did you pass info on junit 5, navigation and selective run already?

@orangy: yeah we spoke brielfy about it with Ranie. Will be on the list for 1.0 potentially.

@kittinunf has left the channel

hey there everybody, just getting started with kotlin/spek and wanted to know if there are any changes/plans for junit 5?

@mkobit: It might help us support certain things, so considering a switch at some point, but want to also discuss with @raniejade if we do it prior to 1.0. Why you ask?

There are several advantages implementing a custom JUnit5 Engine, especially with tooling. We get a gradle plugin and a console runner out of the box, plus a small degree of IDE support via https://github.com/junit-team/junit5/tree/master/junit4-runner. Also, some work has been started for supporting JUnit5 in intellij idea https://github.com/JetBrains/intellij-community/tree/master/plugins/junit5_rt.

I'm inclined to implement it before

1.0

, it's a path of least resistance/work 🙂.

I was just interested in seeing what the plan was for junit4/junit5, and seeing if id be able to try and build an extension on top of junit 5/spek

@mkobit: We’re going to investigate now and if things go well then aim to move to junit 5 for the release.

what do you think about the following solution to the double initialization problem:

fun <T : Any> DescribeBody.subject(block: () -> T) = Resettable(block).apply {
    beforeEach { reset() }
}

class Resettable<out T : Any>(private val init: () -> T) {
    private lateinit var value: T

    fun reset() {
        value = init()
    }

    operator fun invoke() = value
}

example usage:

describe("two subjects") {
    val foo = subject { mutableListOf("foo") }
    val bar = subject { mutableListOf(foo()) }

    context("add to foo") {
        beforeEach {
            foo().add("foo2")
        }

        it("bar's single item should have two items") {
            assertEquals(2, bar().single().size)
        }
    }

    context("add to bar") {
        beforeEach {
            bar().add(mutableListOf("baz"))
        }

        it("foo should have one items") {
            assertEquals(1, foo().size)
        }

        it("bar should have two items") {
            assertEquals(2, bar().size)
        }
    }
}

@kirillrakhman: that’s an already planned feature 🙂 https://github.com/JetBrains/spek/tree/junit5

It’s already implemented in that branch.

@raniejade: will this be available for junit 4, too?

Unfortunately no, we are planning to upgrade to JUnit 5.

@kirillrakhman: also the current implementation only supports one subject. https://github.com/JetBrains/spek/issues/87

hm, isn't this a problem for Android users?

For android integration tests?

did those ever work? currently, I'm toying around with unit tests

I don’t see any problem with Junit 5 on android. Or do you have something in mind?

I just never tried it

Unit testing should be the same when your writing non-android java applications, so I don’t see a problem with using JUnit 5

ok

integration tests is definitely a problem

anyway, my first impression of spek is pretty good. tests are very readable and I like the hierarchical structure

@kirillrakhman: you might be interested in this two features: https://github.com/JetBrains/spek/issues/87 https://github.com/JetBrains/spek/issues/88

@kirillrakhman: nice workaround, but not sure what’s worse — do invoke to get reference to object

foo()

in each test or double initialization written once

Hey guys, I would like to get feedback on two features I'm bringing over from KSpec to Spek, subjects (https://github.com/JetBrains/spek/issues/87) and shared specs (https://github.com/JetBrains/spek/issues/88). The custom JUnit 5 engine is almost complete (check it out here https://github.com/JetBrains/spek/tree/junit5), just need to do some clean and add some tests.

@raniejade: What's the advantage of

subject { Calculator() }

over

val subject : Calculator get() = Calculator()

?

@cedric: every test (it blocks) get their own instance.