In the new 6.2 release, <PR 5806> introduces `Inst...

# kotest-contributors

[Oliver.O]

In the new 6.2 release, PR 5806 introduces InstancePerTest and InstancePerLeaf isolation modes on non-JVM targets, while the 6.2 docs still state

InstancePerTest and InstancePerLeaf are now deprecated due to undefined behavior in edge cases.

Is this intentional?

[Alfonso Ristorato]

Thanks, I don't think we have already released the 6.2 docs, but we'll be sure to check for this before doing so

[Alfonso Ristorato]

nvm, we actually did release the docs 🙂 we'll have to include this ref 🙂

[Oliver.O]

AFAIU, the reasons prompting the deprecations are still valid, but introducing deprecated modes to additional targets seems contradictory, so I was just wondering what I might have missed.

[Alfonso Ristorato]

I think Sam wanted to expose the modes that were actually valid, and in doing so he ended up deciding to expose them all.
I might be wrong, but I believe his thought process was, given how we will never fully deprecate InstancePerTest and InstancePerLeaf - but rather stop doing development on it, we might as well expose them all to users and let them decide (I think when he tried to deprecate them for good there was a mini revolt)

[Oliver.O]

My understanding is that folks expect fresh state per test case, regardless of the nesting level. But to do that in Kotest with anything below the root level requires replaying all higher-level initializations, and that never worked in all cases.

So if the deprecation is now meant to be a soft one with an unlimited lifetime, maybe providing concrete examples of correctness boundaries would help folks make informed decisions.

[sam]

Yeah its soft deprecated in the sense that we can't ever remove it, and it does work, it's just very confusing. If you're using spring for example, when does springs beforeTest callback get invoked? Every level? Root level? Leaf level? You know the issues.

But why is it now "supported" in KMP? - Because the test engine no longer has separate jvm/non-jvm implementations, so it just comes for free. (And the changelog is AI generated 🙂)

I think we should make sure that our docs don't promote the use of these confusing isolation modes. We did the same thing with StringSpec - no reason it really needs to exist since it's just subset of FreeSpec, but it's not like it's ever going to get removed.

[Oliver.O]

Thanks for the clarification! My take is that it would be most helpful to provide just that information: Explaining the "forever" soft deprecation and pointing out the causes of confusion.