Decouple FunctionalTestSetupTrait from the simpletest module

Here is the first suggested option of the resolution

+++ b/core/lib/Drupal/Core/DrupalKernel.php
@@ -776,7 +776,7 @@ protected function moduleData($module) {
-      $settings = $this->getConfigStorage()->read('simpletest.settings');
...
       $parent_profile = !empty($settings['parent_profile']) ? $settings['parent_profile'] : NULL;

+++ b/core/lib/Drupal/Core/Extension/ExtensionDiscovery.php
@@ -233,7 +233,7 @@ public function setProfileDirectoriesFromSettings() {
-      $testing_profile = \Drupal::config('simpletest.settings')->get('parent_profile');
...
       if ($testing_profile && $testing_profile != $profile) {
         $this->profileDirectories[] = drupal_get_path('profile', $testing_profile);
       }

+++ b/core/lib/Drupal/Core/Extension/ModuleExtensionList.php
@@ -111,7 +111,7 @@ protected function getProfileDirectories(ExtensionDiscovery $discovery) {
-    $parent_profile = $this->configFactory->get('simpletest.settings')->get('parent_profile');
...
     if ($parent_profile && !isset($profiles[$parent_profile])) {
       // In case both profile directories contain the same extension, the

Can we decouple here using some of the mechanisms like hooks or events?

1. +++ b/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php
   @@ -107,7 +107,7 @@ protected function prepareSettings() {
        // Add the parent profile's search path to the child site's search paths.
        // @see \Drupal\Core\Extension\ExtensionDiscovery::getProfileDirectories()
   -    $settings['conf']['simpletest.settings']['parent_profile'] = (object) [
   ...
          'value' => $this->originalProfile,
          'required' => TRUE,
        ];
   

   Not really sure about this part. What exactly we can do here?

2. +++ b/core/tests/Drupal/KernelTests/Config/DefaultConfigTest.php
   @@ -35,14 +35,14 @@ class DefaultConfigTest extends KernelTestBase {
   -   * @todo Figure out why simpletest.settings is not installed.
   ...
      public static $skippedConfig = [
        'locale.settings' => ['path: '],
        'syslog.settings' => ['facility: '],
   

   I guess we are able to fix that todo in that issue.

Other changes are related to the code within simpletest module. So I like the idea (second option from the proposed resolution) to introduce another mechanism to pass those configurations.

Also, I find usages of the simpletest.settings config in the generated settings.php files after running tests locally. So there introduced only the 'parent_profile' key with NULL value. I suspect that is set for specific needs and for all running tests and can be moved in some global testing configuration, but I'm not sure is it works as I think.

+++ b/core/lib/Drupal/Core/Extension/ModuleExtensionList.php
@@ -111,7 +111,7 @@ protected function getProfileDirectories(ExtensionDiscovery $discovery) {
-    $parent_profile = $this->configFactory->get('simpletest.settings')->get('parent_profile');
+    $parent_profile = $this->configFactory->get('system.site')->get('test_parent_profile');

We have no schema for this - does it even need to be config? i.e. could it just be Settings instead? Other than that, this is just moving stuff around - looks good - patch is much smaller than I was expecting.

If we leave it as is (Config) or move it to settings, we need a change-record because there might be someone relying on the previous key.

The parent profile stuff was added in #911354: Tests in profiles/[name]/modules cannot be run and cannot use a different profile for running tests - I think we messed up when we moved it to config. It's not really something that should be configured. Let's move it to settings.php as something in $settings['testing'['parent_profile'] - it is not something that should ever be set by a human being and therefore should not be in config.

If someone is relying on the previous key then I think a CR should suffice - it was never meant to be a configurable thing and even if you do currently set it it will be overridden because we write an override to settings.php so maybe mentioning on the CR is not necessary as it is just noise that complicates for no gain.

Since we do

    $settings['settings']['test_parent_site'] = (object) [
      'value' => $this->originalSite,
      'required' => TRUE,
    ];

maybe $settings['settings']['test_parent_profile'] is better than $settings['testing']['parent_profile']

lolz - smart - yet another reason why profiles should be in configuration :). But I'm not convinced that that is the way to go here. At the moment tests that need this kind of have two profiles (at least for searching for modules) and this would mean that now they only have one. Which means that we've changed the underlying behaviour. On the other hand, this means that the test is way more like a real installation as that can only have a single profile.

Also this will break the profile set by \Drupal\Tests\BrowserTestBase::$profile - which is used in \Drupal\Core\Test\FunctionalTestSetupTrait::installParameters()

#22 sounds like a good plan, no reason for this to be config.

As per #16 this doesn't need a change record because even if you set this when you run a test it'll be overridden.

+++ b/core/modules/simpletest/src/KernelTestBase.php
@@ -351,7 +351,7 @@ public function containerBuild(ContainerBuilder $container) {
+        ->register('testing.config_schema_checker', ConfigSchemaChecker::class)

+++ b/core/tests/Drupal/KernelTests/KernelTestBase.php
@@ -532,7 +532,7 @@ public function register(ContainerBuilder $container) {
+        ->register('testing.config_schema_checker', ConfigSchemaChecker::class)

should we add these to simpletest.services.yml or a SimpletestServiceProvider as aliases with a deprecated tag?

At the very least we probably need a change record for them as someone might be using these service IDs in their test..no idea why but it could happen.

Re #26 well these are event listeners which I think are explicitly not API

In that case

Committed 5db19a0 and pushed to 8.8.x. Thanks!

Will unpostpone the follow-up.

Published the change record: https://www.drupal.org/node/3082134