In fact, the CacheWarming test that fails here is misleading; In master, the two test cases,testCacheIsProperlyWarmedWhenTemplatingIsAvailable andtestCacheIsNotWarmedWhenTemplatingIsDisabled fail when the tests are reversed. This shows that the cache pre-warming always takes place if the class hasn't previously been loaded withrequire_once...@tucksaun

This PR effectively re-generates classes that are 'not fresh' while ditching the logic behindrequire_once to tell us whether a class has been loaded before, regardless of whether we have a newer version of the class we want to load instead.

This makes for a much more powerful testing suite, being able to test a Container with a config that changes between test cases.

@fabpot@jakzal@nicolas-grekas - can someone please nudgefabbot.io ?

thanks for reporting this@stampycode !
this should be fixed with#20103

@fabpot,@tucksaun - finding the bug in theCacheWarmingTest was only a side-effect of this ticket - the purpose of which was to merge my PR - is this now being rejected with no reason?

@stampycode problem with this PR in my view is that it introduces quite a lot of code (that could potentially break other people's code) for what I see as an edge case.

@jakzal Surely any change to the Kernel could potentially break other people's code if other people are toying with the Kernel?
Currently what happens, if the cache files are deleted between tests, is the cached files are re-generated and then NOT USED, because therequire_once statement blocks the same file being re-loaded, and php disallows the same class from being declared twice.

In my mind this PR is fixing a bug - you can put debug statements in the parameters.php file and see that the file is being reloaded, but there is no indication that the cache file is not being reloaded when the file is re-generated.

It's not a core deliverable of Symfony to silently block the re-loading of that cache file in a single execution, such as during PHPUnit tests.

It may break people's code if they are depending on this bug existing, but that doesn't sound like a good argument to not fix it.

And this would make PHPUnit and WebTestCase much more powerful.

Loading the kernel class that changes during the request is not a supported use case (this doesn't happen in real life). I think this PR is a wrong solution to the problem since it introduces code in a production class that would only be there for tests.