I asked a while back but didn’t follow up: what wa...

# kotest

[wasyl]

I asked a while back but didn’t follow up: what was the reasoning to remove context block in DescribeSpec? @sam you mentioned (in https://kotlinlang.slack.com/archives/CT0G9SD7Z/p1593192969030900) that now nested describe blocks are allowed, but they were allowed for almost a year, since 3.4 I think. I’m asking primarily since it’s a bit surprising to see such breaking change between 4.0 and 4.1

[sam]

It simplifies the creation of intellij plugins, but it shouldn't have been removed. I will add them back in for 4.1.2 and deprecate them, so your code will work

[wasyl]

If they’re deprecated then we won’t use them regardless, because we use -Werror 🙂 Migration is really straightforward so I don’t mind in terms of that, only I know some of the team here enjoyed the distinction between context and describe since it’s how RSpec works

[wasyl]

We considered our own alias function, but then from what I understand it also wouldn’t play well with IJ plugin, right?

[wasyl]

Yep, with an alias we see duplicated test name error because our context is ignored for the purposes of the check apparently

[sam]

4.1.2 released with context restored to DescribeSpec. It is deprecated but only as a warning.

[wasyl]

Thanks 🙂 I’m afraid we’ll still not be able to use it, but maybe someone will 😉 My 2 questions:
- would bringing back context, thus keeping DescribeSpec more consistent with RSpec, be considered?
- would you accept a contribution to IJ plugin that somehow addresses our issue? Generally we appreciate having a separately named container to differentiate between blocks that change system context vs blocks that perform an action

[wasyl]

I’d have to look at the plugin code, but perhaps a @TestContainer annotation on a method that denotes opening another scope would make sense? I’ll provide more details when I have something, but in general the plugin currently doesn’t play well with neither custom alias or even extracting pieces of test functionality into methods. Since it doesn’t recognise other methods, some of our tests are all red from “duplicate test name” error, even though tests with the same names are nested differently

[sam]

Ok that last point is definitely a major bug. Can you create an example that causes it and I'll get that fixed

[wasyl]

Yep, I plan reporting couple of issues to IJ plugin (especially around instance-per-leaf tests), but most likely tomorrow

[sam]

Instance per leaf with the messed up nesting?

[sam]

I should have remembered your earlier message about wanting to use context because it's consistent with rspec. I thought you just needed a workaround for now. Let me look into supporting context again properly.

[wasyl]

yep, the tests in the “run” window are nested one inside another, with some entries duplicated:

- test1
    - test2
       - test3
         …
                                     -testx

[sam]

If you're using 4.1.x then that was fixed in 4.1.2

[wasyl]

Yess, I confirm what I was seeing is fixed with 4.1.2, great 🙂

[sam]

So we just need to add context back in now properly

[wasyl]

Here’s another thing that doesn’t work properly

[wasyl]

It’s a pattern we have sometimes, and now I see it doesn’t execute assertions 😕 I wanted to paste it as an example of duplicated test name error (which doesn’t appear here, interestingly):

[wasyl]

class SomeClass(
    private val dependency: AtomicInteger
) {

    fun getText() = dependency.get().toString()
}

class UtilMethodExampleSpec : DescribeSpec() {

    val integer = AtomicInteger()
    val sut = SomeClass(integer)

    init {
        describe("SomeClass") {
            withIntValue(4) {
                describe("text") {
                    val result = sut.getText()

                    it("should be '4'") {
                        result shouldBe 4
                    }
                }

                withIntValue(6) {
                    describe("text") {
                        val result = sut.getText()

                        it("should be '6'") {
                            result shouldBe 6
                        }
                    }
                }
            }

            withIntValue(5) {
                describe("text") {
                    val result = sut.getText()

                    it("should be '5'") {
                        result shouldBe 5
                    }
                }
            }

        }
    }

    private suspend fun DescribeScope.withIntValue(value: Int, block: suspend DescribeSpec.() -> Unit) {
        context("given integer value is $value") {
            integer.set(value)
            block()
        }
    }

    override fun isolationMode(): IsolationMode = IsolationMode.InstancePerLeaf
}

[wasyl]

The pattern is to create methods suspend fun DescribeScope.someStateDescription(<state values>, block: suspend DescribeSpec.() -> Unit) to quickly open context/describe blocks which sometimes do multiple things. For this particular example it seems like no test is even executed:

[wasyl]

[sam]

private suspend fun DescribeScope.withIntValue(value: Int, block: suspend DescribeSpec.() -> Unit) {
        context("given integer value is $value") {
            integer.set(value)
            block()
        }
    }

[sam]

That needs to be changed to

[sam]

private suspend fun DescribeScope.withIntValue(value: Int, block: suspend DescribeScope.() -> Unit) {
        context("given integer value is $value") {
            integer.set(value)
            block()
        }
    }

[sam]

The block() is being called on the top level describe, which has no effect

[wasyl]

Ahhh that's right, sorry :/ anyway, I'll be reporting the issues as I go, I tried quickly reproducing something and made a mistake simple smile

[wasyl]

Hey @sam, I just wanted to ask what’s the status of context on DescribeSpec going back. We’re holding back on updating to recent release because context is deprecated (and it shadows our extension) and we have -Werror flag on 😕
I understand if it’s not priority, just then we’ll rename our extension and wait. Or maybe there’s something I can contribute to help with this?

[sam]

It's back in master https://github.com/kotest/kotest/blob/master/kotest-core/src/commonMain/kotlin/io/kotest/core/spec/style/scopes/DescribeSpecRootScope.kt

[sam]

You're just waiting on a release of 4.2

[sam]

You could use the rc1

[wasyl]

That’s great news 🙂 I saw rc release but thought it’s just a technical one, related to github workflow. Is it compatible with IJ plugin?

[sam]

Yes works with 1.0.5 and 1.1.9 plugins

[sam]

4.2.0 final is just waiting on kotlin 1.4 final

[wasyl]

Ah, got it. Do we need Kotlin 1.4 rc as well?

[sam]

It should work on 1.3.72 as well

[wasyl]

We’ll give it a go, thanks a lot!

[sam]

Let me know as I'm releasing 4.2.0.RC2 today and 4.2.0 on Monday

[sam]

So any issues I'll get them fixed asap

[wasyl]

That means Kotlin 1.4 goes out on Monday? 😄