@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?

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

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

It creates a

TestContextManager

for each spec

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

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.

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.

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

ha!

yes

nice

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

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)

Makes sense. Spring does love its global state