Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Starting with Drupal 11.3, all Kernel, Functional and FunctionalJavascript tests must be executed in process isolation. This means that the RunTestsInSeparateProcesses attribute is required for all Kernel, Functional and FunctionalJavascript tests.
Proposed resolution
Add the attribute to all the all Kernel, Functional and FunctionalJavascript tests.
Issue fork examples-3589063
Show commands
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:
- 3589063-add-runtestsinseparateprocesses-attribute
changes, plain diff MR !133 / changes, plain diff MR !132
Comments
Comment #2
oily commentedComment #7
oily commentedComment #8
avpadernoIt is probably better to remove all the PHPUnit tests and rewrite them from scratch.
Tests should verify new commits do not introduce any bug. They should not verify, for example, that every route defined by a module (which do not require any restricted permission to access it) is accessible because that is possibly a test for Drupal core.
Given the changes introduced in the 5.0.x branch, there are probably tests that are outdated. Updating them seems more work than rewritting them from scratch.
Comment #9
oily commentedAh, okay. Makes sense. Do you have ideas on how to break down the new tests as tasks/ subtasks? It sounds a big task for one issue? Perhaps no bigger than the conversion to OOP hooks issue, though? I think the recreation of tests could be done on the more stable of the modules in the 5.0.x, i.e. the ones that work now (manual testing) and are not the subject of issues to change them?
Comment #10
oily commentedFor example, the work on the new controller_example module, how about creating a child issue to write the test(s)? Maybe it would be best to decide for each active issue whether to create a child task to create the tests, on an issue by issue basis? Some tests are likely to be more complex to write than others. Especially if there is a case for writing unit and or kernel tests..
Comment #11
oily commentedRe #8:
So it would seem sensible in the controller_example module, first to include the code from page_example, and then to write tests from scratch only for the routes with custom access checking or other complications like using a custom service for dynamic routing.
Comment #12
oily commentedMaybe create an issue to plan the rewriting of all the tests? Could consider whether to break down the test rewriting into chunks, groups of modules.. Where possible identifying modules where rewrite of the tests has something in common.
Comment #13
avpadernoI would rather create an issue for each of the existing modules, since which tests to add to each module is very specific to each module. I would not open a single issue like the one to convert hooks in OOP hooks.
For new modules, including the ones that replace two or more existing modules, I would first commit them without tests. Once all the existing tests are removed, and they are going to be rewritten from scratch, I would think of tests.
Comment #14
oily commentedRe #13, Okay, I agree.
I will apply that plan to the controller_example module to begin with.
Should the IS for this issue be updated, including the title, with the plan you have just set out?
Comment #15
avpadernoI updated the issue summary. The details about when this issue should be fixed can stay in comments.
Comment #16
avpadernoComment #17
avpadernoI am postponing this issue, since the tests are going to be rewritten from scratch.
Comment #19
oily commentedRe #17: +1