Convert functional tests with suitably simple HTTP requests to kernel tests

not a parent

Drupal\Tests\layout_builder\Functional\LayoutBuilderTest is testing form submissions, so not suitable.

Drupal\Tests\update\Functional\UpdateSemverCoreBaselineTest uses checkForMetaRefresh(), which we can *probably* add to the kernel test UI trait?

Drupal\Tests\jsonapi\Functional\UserTest will need #3582228: add $options and $headers parameters to HttpKernelUiHelperTrait::drupalGet()

Drupal\Tests\rest\Functional\Views\StyleSerializerTest - same, needs to pass options to the request.

Drupal\Tests\block\Functional\BlockTest needs looking at -- some of the inline comments in the test make it sound like the admin form is being tested as well as the result -- which means the test should be in BlockUiTest instead. Needs unpicking.

JsonApiRegressionTest - the test methods which make GET requests should be ok.

There are two I opened while reviewing the original issue.

#3519393: Convert functional tests in navigation module to kernel tests
#3517299: Convert functional tests in help module to kernel tests

Happy if someone wants to rebase those and see if they're suitable.

Do we want to make this a meta and add child issues? I guess this is already 'Plan', so we're not intending to actually move anything in here.

Spun off #3582580: add checkForMetaRefresh() method to HttpKernelUiHelperTrait as a blocker to some of these...

And opened #3582581: Move UpdateContribTest.php to a Kernel test as a child of this. Starting to look into some of the details, I think that's a better candidate for the initial update.module Functional test to move than UpdateSemverCoreBaselineTest (which is all tangled up with other tests via UpdateSemverTestBaselineTrait 😬).

Opened #3583587: Convert some functional tests in system module to kernel tests which converts 11 tests and has a 79.4% reduction in run time on my local env

Made a start on #3587035: convert jsonapi\Functional\UserTest to a kernel test.

What about stuff that extends

https://git.drupalcode.org/project/drupal/-/blob/main/core/modules/rest/...

Those are a big chunk and don't have forms

Similar for jsonapi

@larowlan I don't think there are any drupalGet calls there? Do you suggest we should use the new trait instead of ApiRequestTrait? I suspect most child classes would need a fair amount of setup to be converted to a kernel test, so we'd need a duplicate of ResourceTestBase, EntityResourceTestBase, etc, to start working on them.

> I suspect most child classes would need a fair amount of setup to be converted to a kernel test, so we'd need a duplicate of ResourceTestBase, EntityResourceTestBase, etc,

Yup, I've started digging into that at #3587035: convert jsonapi\Functional\UserTest to a kernel test and there's a lot to do. But what we figure out for the jsonapi module tests should translate to the rest module tests.

I'm writing up some rough notes on the process to help others who may want to try this conversion on other tests:

1. Copy the class rather than move it - while working, you may need to run the original tests to understand how they are doing something.
2. Change the base class to KTB. If the test uses a specialised base class (as in other than BTB), you might want do one of these instead:
-- add a new base class too
-- copy things you find you need from the base class into the test class itself.
-- create a new trait that can be used by both the browser tests you're not changing and the new kernel test
In all approaches, I prefer to copy methods across as I find I need them, rather than everything at once. You may find you change which approach you take, e.g. if you find that most of the helper methods need changing as well.
3. remove the $defaultTheme
4. review the modules - you will need to explicitly add dependencies. Simplest thing is to pick one test method and run it and see how it crashes ;)
5. add setup. you will likely need to set up entity types, tables, and config. Tests can sometimes expect default config settings, for example. See https://www.drupal.org/docs/develop/automated-testing/phpunit-in-drupal/... for a crib sheet. Again, run the test and failures will often show what you're missing -- missing tables, entity types, plugins, services, etc.

Test failures, I have found, are generally due to one of the following:

- missing setup that the browser test got and the kernel test needs to be done explicitly. If values are not as expected, it can be missing config settings, for example.
- SUT code that is remembering state between requests. If a class has a $this->something = a config value or something based on the request, then that won't be getting reset in a kernel test, because we're all in the same request. This will need changing -- either don't persist the value, or add a method that clears it. It's something that will need fixing for #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole anyway!
- things to do with the change in the browser being used. With simple drupalGet() calls this shouldn't be a problem, but more complex uses might need adapting.

Opened #3588363: Convert some tests in Drupal\FunctionalTests namespace to kernel tests