Closed Kantis closed 2 months ago
Hi @Kantis,
Simply letting us inject or access the
ThreadLocal
should be sufficient, since we could then add it as a coroutine context element which the coroutine machinery would then take care of.
Would it be sufficient for Kotest if we introduce a new TestContextManager
constructor (or constructors) that allow you to supply a ThreadLocal<TestContext> testContextHolder
?
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
Kotest is a Kotlin based testing framework. We execute tests on coroutines, which may (or may not) execute on different threads. As such, the
TestContextManager
created for a certain class cannot reliably store theTestContext
as aThreadLocal
.We recently received an issue regarding this.
Could you consider providing the means to provide other storage alternatives?
Simply letting us inject or access the
ThreadLocal
should be sufficient, since we could then add it as a coroutine context element which the coroutine machinery would then take care of.