<@U12AGS8JG> qq just to clarify my understanding, am i right to understand that spring listener will...

# kotest

[mitch]

@sam qq just to clarify my understanding, am i right to understand that spring listener will try to boot up spring before each spec class that summons the bean autowiring?

[sam]

not sure what you mean by boot up string (my knowledge of spring isn't amazing) but it will ask spring to "populate" the bean yes, or it will ask spring to create the bean if it's a constructor injected one

[mitch]

right. yeah i think i understand that similarly because i was reading the code and it does try to create an application context for each spec class

[mitch]

i was asking because my colleague asked me that question so i might cross-check with the expert 😆

[sam]

It creates a

TestContextManager

for each spec

[sam]

That's what the junit support does too

[mitch]

i guess their q is something like this

is it

spec 1 -- application context 1

spec 2 -- application context 2

spec 3 -- application context 3

or does that TestContextManager caches the context such that

spec 1 -- application context 1

spec 2 -- application context 1

spec 3 -- application context 1

[sam]

The manager itself is freshly created for each spec. I'm not sure if it's sharing the beans behind the scenes or creating fresh beans to be used by itself.

[sam]

I'm trying to find the junit one to see what that does

[sam]

So in junit4 it would create a new TestContextManager for each SpringJUnit4ClassRunner, but I don't know if the runner itself is cached between classes.

[mitch]

hmm interesting. thanks @sam i was kinda hoping that it’s doing the first one (creating fresh ones) but we might investigate this. Spring has so much mutable references under the hood.. if it’s akka i might be able to reason about it quite a bit.

[sam]

JUnit5 stores the manager in the extension store so I guess in junit5 its shared

[mitch]

ha!

[mitch]

in kotest we’re creating them fresh

[sam]

yes

[mitch]

nice

[sam]

in kotest, the manager is created per class, same as junit 4

[sam]

5 shares the manager

[thanksforallthefish]

you sure? creating a fresh context per class would mean in most situation (unless graalvm) your tests would be really really slow. pretty sure the context is shared, but will double check as soon as I am on the project using kotest (which unfortunately is in 2 weeks)

[thanksforallthefish]

I mean, the code really seems to recreate a manager for each spec, but experience seems to disagree

[thanksforallthefish]

ok, if you look a bit deeper, the context is cached by Spring itself, but disclaimer, it is Spring code, it tends to be well written but complex, I might read it wrong (TestContextManager -> BootstrapUtils)

[sam]

Makes sense. Spring does love its global state