Fixing phpunit tests on drupal.org for localgov_services (and others)

[finnlewis]

Before we finalise the move to drupal.org, we want to make sure the phpunit tests are passing for Drupal 10 (previous major).

On localgov_services we have some interesting test failures, which @tonypaulbarker, @andybroomfield and I were looking at yesterday.

For example, see https://git.drupalcode.org/project/localgov_services/-/jobs/6831419#L80

We seem to be getting some interesting behaviour where /web is being added multiple times to redirections and paths.

See

https://project.pages.drupalcode.org/-/localgov_services/-/jobs/6831419/artifacts/web/sites/simpletest/browser_output/Drupal_Tests_localgov_services_Functional_WorkflowsIntegrationTest-13-46152139.html

It looks like all tests on drupal.org end up running in http://localhost/web/, which is interesting. I couldn't find any documentation about this or if it has implications for how we need to write tests. @andybroomfield suggested that if we need to account for Drupal being installed in a sub-directory, maybe we need to get and set paths with this in mind.

The first test failure was this:

1) Drupal\Tests\localgov_services_navigation\FunctionalJavascript\LandingPageChildrenTest::testServiceLandingPageLink
Behat\Mink\Exception\ExpectationException: The field "edit-localgov-common-tasks-1-uri" value is "/web/foo", but "/foo" expected.
/builds/project/localgov_services/vendor/behat/mink/src/WebAssert.php:888
/builds/project/localgov_services/vendor/behat/mink/src/WebAssert.php:781
/builds/project/localgov_services/web/core/tests/Drupal/Tests/WebAssert.php:991
/builds/project/localgov_services/modules/localgov_services_navigation/tests/src/FunctionalJavascript/LandingPageChildrenTest.php:149
/builds/project/localgov_services/vendor/phpunit/phpunit/src/Framework/TestResult.php:729

@andybroomfield your suggestion to grab the path with $child[2]->toUrl()->toString() worked ! :)

https://git.drupalcode.org/project/localgov_services/-/commit/a917be7cf2c4995e61615a917a5bee131be136ee

So maybe all these test failures are related to Drupal living in a sub-directory of /web on drupal.org and we need to accommodate this in our tests?

Copying @stephen-cox @ekes @millnut @Adnan-cds for info and incase anyone else has intel to share on this front!

[millnut]

@finnlewis yep I agree that @andybroomfield fix is the way to go to handle this

[tonypaulbarker]

For mimicking running the tests locally I found that ddev provides some tools specifically for Drupal contrib. https://github.com/ddev/ddev-drupal-contrib

[finnlewis]

Another thing may help in certain cases is that drupal.org's testbot runs tests in a subdirectory Drupal setup, for certain path related logic if it can not handle subdirectory properly, it might cause the failure.

From https://www.drupal.org/docs/develop/automated-testing/phpunit-in-drupal/running-phpunit-tests#testbot-fails

So this does suggest we need to make sure the tests can deal with a Drupal install in a subdirectory, good to know!

[tonypaulbarker]

@finnlewis this is also vital information - we might need to wait 24 hours after pushing changes to run tests.

“After pushing this change to drupal.org it can take up to 24 hours for testbot to become aware of your new dependency.”

[finnlewis]

Thanks all! Getting there!

I now have a test that is getting the page with

    $this->drupalGet($status->toUrl()->toString());

but the actual path it tries to get is

http://localhost/web/web/test-service/status/wkcdlhal

So, why the double /web?

See

https://project.pages.drupalcode.org/-/localgov_services/-/jobs/6842834/artifacts/web/sites/simpletest/browser_output/Drupal_Tests_localgov_services_status_Functional_ServiceStatusTest-4-97290182.html

Locally the same test goes to:

GET request to: http://web/test-service/status/yufb2i47

(Locally http://web is the internal hostname of the ddev web server, which slightly confuses things!)

[finnlewis]

Related? https://www.drupal.org/project/drupal/issues/3440424

[andybroomfield]

Just to note there are some other weird oddities when running LGD in a sub directory.
I posted these screenshots on slack. There are defiantly some path issues with the auto generated path aliases when running in a sub directory.

Publishing a page adds the url with /web. but the page becomes /web/web and results in a 404.

Dragging the page from the helper tool (the test that was broken) puts in /web/web (the path that is not found).

[finnlewis]

@andybroomfield indeed - I've confirmed this locally.

A fresh install of LocalGov Drupal in a sub-directory.

Create a landing page, alias looks OK: https://subdirtest.ddev.site/subdir/landing-page

Create a service page, and reference the landing page.

Alias now has an extra /subdir in the path: https://subdirtest.ddev.site/subdir/subdir/landing-page/service-page

[finnlewis]

@ctorgalson has a similar issue with language prefixes. Solves with a hook_pathauto_alias_alter to scan the string and get rid of unwanted portions.

Maybe we need to do the same?

[finnlewis]

I was debugging this code:
https://github.com/localgovdrupal/localgov_services/blob/2.x/modules/localgov_services_navigation/localgov_services_navigation.module#L68C86-L68C139

And it wasn't triggering.

@ekes mentions that the parent (service landing page) url alias INCLUDES the subdirectory (or language string) then we might also want to strip it at this place.

Could we be using better tokens?

Do we need to code for exceptions?

[finnlewis]

@ekes thinks we need a different token and if one does not exist we should make one!

:)

Passing to @ekes to take a look.

[ekes]

We're using ...:url:relative which is https://git.drupalcode.org/project/token/-/blob/8.x-1.16/token.tokens.inc?ref_type=tags#L1008 looks like we should be using ...:url:path https://git.drupalcode.org/project/token/-/blob/8.x-1.16/token.tokens.inc?ref_type=tags#L991 I'll look out for where we're doing this and pull together PR(s).