Provide a standard way for tests to find core modules without loading experimental modules

+++ b/core/tests/Drupal/KernelTests/KernelTestBase.php
@@ -1084,6 +1084,24 @@ protected function isTestInIsolation() {
   /**
+   * Gets all core modules.
+   *
+   * Excludes contrib, hidden, experimental, already enabled modules, and
+   * modules in the Testing package.
+   *
+   * @return \Drupal\Core\Extension\Extension[]
+   *   Array of all core modules and their data.
+   */
+  protected function getCoreModules() {
+    return array_filter(system_rebuild_module_data(), function ($module) {
+      if ($module->origin !== 'core' || !empty($module->info['hidden']) || $module->status == TRUE || $module->info['package'] == 'Testing' || $module->info['package'] == 'Core (Experimental)') {
+        return FALSE;
+      }
+      return TRUE;
+    });
+  }

Is this something we could provide on the level of a trait so BrowserTestBase can use it as well?

A trait would be a good idea. I agree, setting to needs work based on #3

Setting this to rtbc. I have one minor nitpick but that is not nearly enough to set this back to nw.

+++ b/core/tests/Drupal/Tests/Traits/Core/ModuleTrait.php
@@ -0,0 +1,37 @@
+      $return = $module->origin === 'core'
+        && empty($module->info['hidden'])
+        && $module->status == FALSE
+        && $module->info['package'] !== 'Testing'
+        && $module->info['package'] !== 'Core (Experimental)';
+      return $return;

This doesn't have to go in an intermediary variable and it could be returned without it.

Looks great!

Hmm... I wrote a comment on this yesterday and dug out an issue but somehow it got lost.

I think there is a big difference between a beta stability experimental module and an alpha. Beta ones need to pass these tests - alphas we could exclude them. So for me we should be doing #2656994: Experimental modules should have their own version numbers first.

@tim.plunkett I think adding a boolean to include them and then preserving the status quo is a good way to go. We can then expand this argument to accept a string representing an experimental module stability in #2656994: Experimental modules should have their own version numbers.

That way we get the DRY and improved module selection now (ie. making it easier to exclude non-core modules) and incrementally improve this when possible.

+++ b/core/tests/Drupal/Tests/Traits/Core/ModuleTrait.php
@@ -0,0 +1,33 @@
+    return array_filter(system_rebuild_module_data(), function (Extension $module) {

system_rebuild_module_data() is deprecated.

During the bootstrap process, core/test/bootstrap.php finds extensions so it can discover their tests: https://git.drupalcode.org/project/drupal/blob/8.8.x/core/tests/bootstra...

So you can call drupal_phpunit_contrib_extension_directory_roots() in some circumstances. But it would be better to have a helper class that knows how to do this and isn't ever going to be the system under test. That could then be used by tests, and also replace the code in bootstrap.php.

+++ b/core/tests/Drupal/Tests/Traits/Core/ModuleTrait.php
@@ -0,0 +1,33 @@
+    return array_filter(system_rebuild_module_data(), function (Extension $module) {

system_rebuild_module_data() is the system under test, and it also is replaced by a service so for instance under unit tests it won't be available. #2926068: Deprecate system_rebuild_module_data() and remove usages in core

By now only patch reroll

This would most likely need to skip also deprecated core modules. How they should be identified, currently there is no means for it (apart just listing them as in #3062281: Deprecate block_place module for removal in Drupal 9 in trait Drupal\Tests\DeprecatedModulesTestTrait.

Would it make sense to add an optional key to .info.yml files (deprecated: TRUE as the first thing from the top of my head)?