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

Command icon 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:

About issue forks

Comments

oily created an issue. See original summary.

oily’s picture

oily commented
Related issues: +#3589066: Fix deprecation notices triggered by functional tests

oily opened merge request !132

oily changed the visibility of the branch 3589063-add-runtestsinseparateprocesses-attribute to hidden.

oily closed merge request !132

oily opened merge request !133

oily’s picture

oily commented
Status: Active » Needs review
avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

It 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.

oily’s picture

oily commented

Ah, 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?

oily’s picture

oily commented

For 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..

oily’s picture

oily commented

Re #8:

They should not verify, for example, that every route defined by a module (which do not require any restricted permission to access it) ...

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.

oily’s picture

oily commented

Maybe 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.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

I 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.

oily’s picture

oily commented

Re #13, Okay, I agree.

For new modules, including the ones that replace two or more existing modules, I would first commit them without tests.

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?

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Title: Add #[RunTestsInSeparateProcesses] attribute to FunctionalJavascript test classes » Add #[RunTestsInSeparateProcesses] attribute to test classes
Issue summary: View changes

I updated the issue summary. The details about when this issue should be fixed can stay in comments.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Title: Add #[RunTestsInSeparateProcesses] attribute to test classes » Add the RunTestsInSeparateProcesses attribute to test classes