is it frowned upon to add custom test context to a say Abstr | Kotlintest

"Boolean" {
    val config = createConfig {
        "some.boolean.value=true"
    }
    getValue<Boolean>("some.boolean.value", config) shouldBe true
}

becomes:

"Boolean2" {
    withConfig {
        "some.boolean.value=true"
    }
    getValue<Boolean>("some.boolean.value") shouldBe true
}

which is subtly different but nicer to read, i think

done via adding:

private fun AbstractShouldSpec.ShouldScope.withConfig(block: () -> String) {
        val config = createConfig { block() }
        this.context.putMetaData("config", config)
    }

    private inline fun <reified T : Any> AbstractShouldSpec.ShouldScope.getValue(path: String): T {
        val config = this.context.metaData()["config"] as ConfigSource
        val getter = config.getterFor(T::class)
        return getter(path)
    }

sam

2 years ago

Are you using that metadata stuff a lot ?

It’s been removed from 4.0 currently

bbaldino

2 years ago

ah interesting...this is the first time i thought to play with it...i do think it's quite nice for this though 🙂

is there another way to accomplish something like this?

sam

2 years ago

Yeah I could put it back in

I thnk I removed it when trying to get multiplatform working

Why don’t you just create a private val config = Config() in your test file ?

bbaldino

2 years ago

yeah, i could create one big one i guess. i was creating one with just the configuration for each test case

it is nice to have the config close to the test...makes things like typos easier to spot when they're right next to eachother (since this involves freeform strings)

LeoColman

2 years ago

Won't you get overloaded with different classes and configurations once your test suite start growing?

I'm a fan of having things doing one specific thing, but when writing a lot of tests, this gets messy for me

bbaldino

2 years ago

does this not only add to the test context specific to this test/scope?

i assumed since it's defined on

ShouldScope

it was only local to that

LeoColman

2 years ago

I believe it is specific, yes, but my point is that creating so many specific stuff may become cumbersome for you to code, won't it?

bbaldino

2 years ago

i think i'm missing what you mean...doing it this way saved me code from how i'd do it without this way. if by "specific" you mean: custom and non-idiomatic for kotlintest, which therefore may go away..then yes i'd agree, that's why i was asking.

LeoColman

2 years ago

What I mean is that I don't usually write code this way. I usually just hardcode the boolean inside the test and let go of it instead of creating some abstractions to make it more specific

No issues with your approach

I'm just questioning if you don't feel that when your codebase grows, this configs will get a little bit hard to manage

bbaldino

2 years ago

oh, well in this case the parsing of a config value is what i'm testing

LeoColman

2 years ago

Ah, I see

View count: 1

Join thread in Slack