Postponed
Project:
Drupal core
Version:
main
Component:
phpunit
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
7 Oct 2026 at 10:12 UTC
Updated:
19 Oct 2026 at 12:10 UTC
Jump to comment: Most recent
Kernel tests force a memory backend for cache bins.
If we use the database cache and share the bins between methods, this can re-use discovery and other expensive to build cache items.
In local profiling, it's saving about 300ms or so from each method of NodeTypeValidationTest but also causes at least one test failure.
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
catchWorks, but fails because it's working.
Comment #4
catchResolved the test failures:
1. In KernelTestBase::enableModules() we need to clear the plugin caches to match ModuleInstaller::install() - this is because the caches can be populated before the ::enableModules() call which generally they wouldn't be in kernel tests before this change. There's a possibility there's some manual cache clears in existing tests that could be dropped but didn't look yet.
2. We need to exclude cache tables from the shared database state validation because they're ephemeral e.g. we allow those to be created and not cleaned up in a specific test method since they're created on-demand.
Comment #5
catchComment #6
catchThe plugin issue is making me wonder if we should forbid enabling a module during a test method when the environment is shared.
Tests that do this then have three options:
1. Add the module to static::$modules
2. Split the method(s) out to a separate test
(both of these will also be a performance improvement since it means less total container rebuilds)
3. Don't share the environment (can be combined with #2
Comment #7
plachI agree, I reached the same conclusion here, see this commit.
Comment #8
catch@plach could we move the check to ::tearDown() maybe? (or am I missing something and it would already cover all cases?). Also what do you think about splitting that out to its own issue?
Comment #9
plachYep, I opened #3631699: Prevent module list changes outside of setup when sharing the test environment.
Comment #10
catchThanks. Postponing this on that one #3631699: Prevent module list changes outside of setup when sharing the test environment.