In kotlintest I was able to add arbitrary metadata via the `testContext` member in a `ShouldScope`, ...

# kotest

[bbaldino]

In kotlintest I was able to add arbitrary metadata via the testContext member in a ShouldScope, does something equivalent exist in kotest?

[bbaldino]

Looking through ShouldSpecContextScope I haven't found anything, but hoping maybe that feature is done another way now

[wasyl]

I looked for such feature some time ago (basically any way to add an object or key-value map) but didn’t find one. What’s your use case?

[bbaldino]

I have some tests that validate behavior based on values from configuration, so I had a helper withConfig(...) that set a config and then another helper getValue to retrieve a value from that set config. I ended up having to create my own scope class which has the configuration set. So I had to do it within that scope, i.e.:

withConfig(...) {
  ...
  getValue(...) shouldBe ...
}

[wasyl]

Right, that reminded me: since tests are coroutines, maybe you can put whatever data you want in its coroutineContext?

[bbaldino]

Hm, yeah that's an interesting idea

[sam]

Can you just create a variable in the scope and reference that ?

[sam]

You don't need to assign it and then pull it back out ?

[bbaldino]

Yeah the helpers I added do write/read a variable in the scope

[bbaldino]

It by no means requires the metadata helpers, but they were nice.

[sam]

We can always add new features 🙂

[sam]

Can you write up a pseudo code example of what you were using them for ?

[bbaldino]

Ya, I'll grab link to the old test file in GitHub when I get a minute

[bbaldino]

Here was the helper before (using test metadata) https://github.com/jitsi/jicoco/blob/8d7369a8c957bd56a211ed2c43c19bfcf4a5920d/jicoco-config/src/test/kotlin/org/jitsi/config/TypesafeConfigSourceTest.kt#L115 and here is after: https://github.com/jitsi/jicoco/blob/master/jicoco-config/src/test/kotlin/org/jitsi/config/TypesafeConfigSourceTest.kt#L122

[bbaldino]

In this scenario, the after may be best anyway because it eliminates any chance of issues with sharing the same instance. ¯\_(ツ)_/¯