[PP-1] Convert functional tests in help module to kernel tests

mstrelan → changed the visibility of the branch 3390193-add-drupalget-with-mink-to-kerneltestbase to hidden.

Added an MR against 3390193-add-drupalget-with-mink-to-kerneltestbase but since it's against that branch it doesn't appear on the issue page, and the pipelines don't work. But I did it this way so we can see only the changes to Help module and not all the changes in the parent issue.

https://git.drupalcode.org/issue/drupal-3517299/-/merge_requests/1

It was a little annoying having to deal with the fact that we can't perform multiple requests in the same test, but overall it's still faster for the cases that I split. My test times below:

MySQL
ExperimentalHelpTest - Kernel 6.348s, Functional 13.550s
HelpBlockTest - Kernel 8.376s, Functional 13.642s
HelpPageOrderTest - Kernel 3.216s, Functional 14.067s
HelpPageReverseOrderTest - Kernel 3.212s, Functional 13.407s
NoHelpTest - Kernel 7.468s, Functional 15.771s

Total: Kernel 28.62s, Functional 70.437s

MySQL w/ tmpfs
ExperimentalHelpTest - Kernel 3.396s, Functional 6.374s
HelpBlockTest - Kernel 4.992s, Functional 5.254s
HelpPageOrderTest - Kernel 1.686s, Functional 5.254s
HelpPageReverseOrderTest - Kernel 1.700s, Functional 5.404s
NoHelpTest - Kernel 3.574s, Functional 5.754s

Total: Kernel 15.348, Functional 28.04s

So for MySQL with a normal filesystem this is a massive improvement! For tmpfs it's a decent improvement for the tests that only had one drupalGet, but it's much less of an improvement when the test had to be split and we repeat the setup tasks. It might be worth waiting for 📌 Allows DrupalKernel::handle to handle more than one requests (rough support for PHP-PM) Needs work for those tests.

I investigated the multiple requests issue a little further, and it turns out the only issue is that the paths weren't prefixed with a preceding slash, so the path was appended to the path of the previous request resulting in 404s. After fixing those the updated timing is below.

MySQL
ExperimentalHelpTest - Kernel 3.246s, Functional 13.550s
HelpBlockTest - Kernel 2.818s, Functional 13.642s
HelpPageOrderTest - Kernel 3.216s, Functional 14.067s
HelpPageReverseOrderTest - Kernel 3.212s, Functional 13.407s
NoHelpTest - Kernel 3.831s, Functional 15.771s

Total: Kernel 16.323s, Functional 70.437s

MySQL w/ tmpfs
ExperimentalHelpTest - Kernel 1.739s, Functional 6.374s
HelpBlockTest - Kernel 1.634s, Functional 5.254s
HelpPageOrderTest - Kernel 1.686s, Functional 5.254s
HelpPageReverseOrderTest - Kernel 1.700s, Functional 5.404s
NoHelpTest - Kernel 1.754s, Functional 5.754s

Total: Kernel 8.513s, Functional 28.04s

Those numbers make this much more compelling.

Thanks for doing a trial run like this! Very helpful and encouraging that the parent issue is on the right track.

If a branch off an issue branch confuses the tooling so much, probably not the end of the world to have an initial commit of ✨ Add drupalGet() to KernelTestBase Active in here, no? The changes tab will be bloated, but it should be fairly simple to review changes via each proceeding commit...

Anyway, thanks again!

@dww sure, I've created an MR against 11.x. As a bonus you don't have to review it one commit at a time because all the changes are limited to the help module, other than a7f43433.

Added 2 more, HelpTest and HelpTopicTest, both of this are much faster now but I don't have the numbers. I did have a go at HelpTopicsSyntaxTest but it was actually significantly slower!

> and it turns out the only issue is that the paths weren't prefixed with a preceding slash, so the path was appended to the path of the previous request resulting in 404s

Can you explain a bit more about where this path appending thing happens? Is it something we can maybe fix?
Though OTOH, since the Drupal convention is now that paths should have the initial slash, it's probably a good thing to add that consistently.

I've had a look at your patch on the other issue for converting BlockContentPageViewTest. I'm honestly confused by what this failing test is doing anyway:

  public function testPageEdit(): void {
    $block = $this->createBlockContent();

    // Attempt to view the block.
    $this->drupalGet('block-content/' . $block->id());

    // Ensure user was able to view the block.
    $this->assertSession()->statusCodeEquals(200);
    $this->drupalGet('/block-content-test');
    $this->assertSession()->pageTextContains('This block is broken or missing. You may be missing content or you might need to install the original module.');
  }

Why would the block report as being broken? What's causing it to be broken? This test needs to explain what it is doing!

Can you explain a bit more about where this path appending thing happens? Is it something we can maybe fix?

I'm offline for over a week now but when from what I recall you can see it in the html output for ExperimentalHelpTest if you remove the slash and run the test. Didn't look at what was causing it.

Why would the block report as being broken? What's causing it to be broken? This test needs to explain what it is doing!

IIRC there is a test module that includes config for a block, but that block is referencing the uuid of a block content entity that doesn't exist. Couldn't tell you why, but it's not really relevant. I think let's ignore that test for now.