Yes, exactly! I guess that was an easier way of saying it :)

e.g,. this javascript suite passes using mocha:

const assert = require('assert');

describe("Nesting", () => {
    var foo = "initial";
    var counterOne = 0;
    var counterTwo = 0;
    var counterThree = 0;

    before(() => {
        foo = "bar";
        counterOne++;
    });

    it("foo should be bar", () => {
        assert.equal(foo, "bar");
        assert.equal(counterOne, 1);
    });

    it("before() should have been called only once", () =>  {
        assert.equal(foo, "bar");
        assert.equal(counterOne, 1);
    });

    it("counterTwo should be 0", () =>  {
        assert.equal(counterTwo, 0);
    });

    it("counterThree should be 0", () =>  {
        assert.equal(counterThree, 0);
    });

    describe("nested level 1", () => {
        before(() => {
            foo = "buzz";
            counterTwo++;
        });

        it("foo should be buzz", () => {
            assert.equal(foo, "buzz");
        });

        it("and counterOne should be 1", () => {
            assert.equal(counterOne, 1);
        });

        it("and counterTwo should be 1", () => {
            assert.equal(counterTwo, 1);
        });

        describe("nested level 2", () => {
            before(() => {
                foo = "jazz";
                counterThree++;
            });

            it("foo should be jazz", () => {
                assert.equal(foo, "jazz");
            });

            it("and counterOne should be 1", () => {
                assert.equal(counterOne, 1);
            });

            it("and counterTwo should be 1", () => {
                assert.equal(counterTwo, 1);
            });

            it("and counterThree should be 1", () => {
                assert.equal(counterThree, 1);
            });
        });
    });
});

We could add this and call it beforeScope to make it clear it only runs
before that particular scope.

That would be awesome. Thanks!

We can put this in 5.2, which is due in a month or so.

I'd suggest to think carefully about choosing a name for this particular callback. We already have some ambiguity with callback names for historic reasons. We currently have:

Historically:

• beforeTest - runs before all containers and leaf tests

Newish:

• beforeEach - runs before all leaf tests (naming suboptimal as beforeTest already existed, but this naming is used in a lot of other frameworks for the specified behavior)
• beforeContainer - runs before all containers
• beforeAny - runs before all containers and leaf tests (same as beforeTest and meant as a replacement in the long run)

Instead of introducing yet another concept with scope, I would throw something quite literal like beforeThisContainer into the mix. Might not be as elegant of a name, but it describes pretty clearly what the difference to the standard beforeContainer is.

I was thinking the same thing, @Reevn. Maybe even beforeThisContainerOnce but that's getting a little too verbose.

I'm new to Kotest and Kotlin, so please forgive my naivety, but I honestly don't get why there aren't just two "before" callbacks: a beforeAll and a beforeEach. I think they cover every possibility I've ever run into in the 15 years I've been using a "describe" style to write tests. Perhaps it's something to do with running tests in parallel? Either way, I really appreciate the new feature.

It's a combination of trying to make a really flexible test framework and historical reasons. I've had some of the same questions in the past and have been made aware that people are writing tests in pretty different styles. Some people like to put test code inside a "container", but without wrapping it in a "leaf test". For those people for example it is important that something like beforeTest executes before the "container" as well (and not just for tests inside the container).

I personally did not expect that and needed the classical beforeEach behavior that only executes before a "leaf test", and beforeTest executes twice in this case. That's when beforeEach and beforeContainer was introduced, to have more flexibility on when exactly you want to execute setup code.

Your issue adds another use-case to the mix, so probably another callback will be born 🙂. Offering this kind of flexibility is the reason why there are so many different callbacks and styles of writing tests.

Thanks for detailed response, @Reevn!

beforeTest is a confusing name but as @Reevn says, history. I'd love it if beforeTest was only leaf, but alas.

beforeScope is a good name I think because the lambdas are called scopes in kotest - container scope, test scope. But I agree that we need to tread carefully.

Another option is simply overloading beforeContainer to have a paramaeter

beforeContainer(inherit = false) { }

I'd personally like to see this new callback be called from within the container. Main reason is I like to set up empty variables inside the container and then assign values to them inside the before* function. Basically setting up a SUT and possibly related variables for the tests within the container. I guess I'm thinking of this as not "before container" but as "before all tests in container."

Yeah it's just a matter of choosing a good name.

beforeScope / setup / teardown / etc,

Something like beforeThisContainerOnly is descriptive but ugly.

I think that beforeRootContainer would be semantically equivalent to beforeThisContainerOnly, but nicer.

What about just before ?

I think before is best (for me anyway) because it aligns with some other test frameworks. For some reason I was under the impression that before couldn't be used in Kotest, but not sure why I thought that.

With the current names I think just before does not differentiate itself from the existing lifecycle callbacks. It would be the most generic before* function, but it does something pretty specific. I don't think a new user would see beforeEach, beforeTest, beforeAny, beforeContainer and then before, and intuitively understand that before is just beforeContainer but only for the current container.

Good point @Reevn

What if we used @DslMarker to restrict access to the root Spec when using beforeTest, beforeEach, beforeAny, beforeContainer, and before could be made available only on ContainerScope. Would that make it intuitive?

@Kantis I don't think that restricting the function to the ContainerScope helps to make users understand that it is not inherited to other children ContainerScopes. That's my personal opinion at least.

I'll +1 @sksamuel's suggestion earlier in the thread:

beforeContainer(inherit = false) { }

It already uses the function that is responsible for setting up a container scope, so no new concept or naming introduced, while making it configurable via a parameter to not inherit this callback to children containers. Looks like a pretty good addition to existing API without adding a lot more complexity to the mix (from the public API perspective).

Following the thread and seeing all the suggestions I also think

beforeContainer(inherit = false) { } 

is pretty much on point. It is clear from reading it what will happen. Also as @Reevn mentioned the concept of beforeContainer already exists, with this change having the possibility to "limit" with an additional parameter. Awesome.

My issue with using beforeContainer is that's outside the container. I want something that is before the tests within a container -- in that case it makes more intuitive sense (and is consistent with other frameworks that Kotest's nesting was based on) to put the new hook inside the container that contains the tests. Having it outside the container makes the test code confusing to me.

However, I just realized that the following works. Basically removing the before hooks from my first example and putting the code directly inside the container. Unless there's a drawback I'm not seeing, I think this actually fixes the issue for me. I probably didn't realize this when I filed this issue in the first place since I had only been using kotest for a week or so at the time. It would still be nice to have a before<something> hook for consistency/clarity.

EDIT: The below works as a "before" hook, but there's no clean equivalent "after" hook.

package foo.bar

import io.kotest.core.spec.style.DescribeSpec
import io.kotest.matchers.shouldBe

class WidgetTest : DescribeSpec({
    var foo = "initial"
    var counterOne = 0
    var counterTwo = 0
    var counterThree = 0

    foo = "bar"
    counterOne++

    it("foo should be bar") {
        foo shouldBe "bar"
        counterOne shouldBe 1
    }

    it("beforeSpec should have been called only once") {
        foo shouldBe "bar"
        counterOne shouldBe 1
    }

    it("counterTwo should be 0") {
        counterTwo shouldBe 0
    }

    it("counterThree should be 0") {
        counterThree shouldBe 0
    }

    describe("nested level 1") {
        foo = "buzz"
        counterTwo++

        it("foo should be buzz") {
            foo shouldBe "buzz"
        }

        it("and counterOne should be 1") {
            counterOne shouldBe 1
        }

        it("and counterTwo should be 1") {
            counterTwo shouldBe 1
        }

        describe("nested level 2") {
            foo = "jazz"
            counterThree++

            it("foo should be jazz") {
                foo shouldBe "jazz"
            }

            it("and counterOne should be 1") {
                counterOne shouldBe 1
            }

            it("and counterTwo should be 1") {
                counterTwo shouldBe 1
            }

            it("and counterThree should be 1") {
                counterThree shouldBe 1
            }
        }
    }
})

My issue with using beforeContainer is that's outside the container. I want something that is before the tests within a container

I see. That would mean if you have following code example:

class TestSpec : UnitSpec({

    beforeContainer {
        println("beforeContainer: ${it.displayName}")
    }

    describe("first container") {
        beforeContainer {
            println("Another beforeContainer: ${it.displayName}")
        }

        describe("with nested") {
            it("does something") {

            }
        }

        it("does something else") {

        }
    }
})

it will print:

beforeContainer: first container
beforeContainer: with nested
Another beforeContainer: with nested

So by introducing a parameter inherit = false it will only honor the first level child containers, but not the actual current container scope. This would probably require something like beforeThisContainer like @Reevn said, acting similar than beforeSpec, but for the current container scope.

True, but it's also unconventional :)

Yep, that I agree with.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Bump for staleness

Just to give more ❤️ to the feature, here's my use case:

class TestingTest : BehaviorSpec({
    beforeSpec {
        dbHelper.createTableIfNotExists()
    }

    beforeContainer {
        dbHelper.deleteAll()
    }

    Given("Feature X with dataset Y in DB") {
        // prepare fixtures
        // add some data to DB
        // do other stuff

        When("subject does something") {
            subject.doSomething()

            Then("foo should be foo") {
                "foo" shouldBe "foo"
            }
            Then("bar should be bar") {
                "bar" shouldBe "bar"
            }
        }
    }
})

Now, as discussed, beforeContainer is gonna delete all the data added in Given container while executing When container which is not what we want. The only solution I can think of is to move "given" statements to "when" container which is a bit weird, considering the terminology.
This limitation makes this style unusable (at least for me) with respect to readability. The fact that no one pointed this out earlier, tells me maybe there is a better way to do this 🤷? (happy to learn 🙂)
Anyhow, would be wonderful if someone can give us a guesstimation on the availability of the feature. Thanks.
PS: I'm new to Kotlin, not sure how much, but let me know if I can help with anything.

Any chance this will be added soon? I'm fine with any name really.

This feature might go a long ways toward convincing co-workers to use this framework.

I agree, this would help convince coworkers to adopt kotest. I'm rather new to kotlin, but would be willing to try doing a pull request, but I need a bit of guidance on how to do that. I'm having trouble understanding how all the hooks work.

I think kotest would be perfect if it had this feature.

I think the name before and after without qualifier might be the right terminology. @Kantis thoughts?

how about beforeCurrent, afterCurrent? I think it helps distinguish itself from other hooks. But I wouldn't say no to just before/after either. :)

class TestingTest : BehaviorSpec({
    beforeSpec {
        dbHelper.createTableIfNotExists()
    }

    beforeContainer {
        dbHelper.deleteAll()
    }

    Given("Feature X with dataset Y in DB") {
        beforeCurrent { prepareFixtures() }
        afterCurrent { teardownDb() }
        afterEach { truncateTables() }

        When("subject does something") {
            subject.doSomething()

            Then("foo should be foo") {
                "foo" shouldBe "foo"
            }
            Then("bar should be bar") {
                "bar" shouldBe "bar"
            }
        }
    }
})

Hmmm I'm not keen on that personally :)

Alright, go with before, after then. You're the native english-speaker after all.😁

I communicate in grunts.

Was about to start using kotest in a project, but then stumbled upon this hook missing. Very much looking forward to this feature. Thanks!

My workaround for BehaviorSpec for now:

abstract class BeforeEachCapableBehaviorSpec(body: BehaviorSpec.() -> Unit = {}) : BehaviorSpec(body) {

    final override suspend fun beforeContainer(testCase: TestCase) {
        if (testCase.parent == null) {
            beforeEach()
        }
    }

    fun beforeEach(block: () -> Unit) {
        beforeContainer {
            if (it.parent == null) {
                block()
            }
        }
    }

    open fun beforeEach() {}

    final override suspend fun afterContainer(testCase: TestCase, result: TestResult) {
        if (testCase.parent == null) {
            afterEach()
        }
    }

    open fun afterEach() {}

    fun afterEach(block: () -> Unit) {
        afterContainer { (testCase, _) ->
            if (testCase.parent == null) {
                block()
            }
        }
    }
}

Method names are like that to better match JUnit's annotation names.