Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Follow-up to #697760: Replace getInfo() in tests with native phpDoc + annotations (following PHPUnit)
Objective
-
/core/tests/bootstrap.php
contains custom code for discovering Drupal extensions + registering their namespaces + test namespaces. -
The intended logic is identical to
TestDiscovery
- duplicate code.
Proposed solution
-
Replace the custom code and call
TestDiscovery::registerNamespaces()
instead.→ No more duplicated code. Single code path. Simplified maintenance. Less bugs.
Comment | File | Size | Author |
---|---|---|---|
#8 | 2301873_poc_8.patch | 4.34 KB | Mile23 |
#8 | 2301873_big_8.patch | 35.19 KB | Mile23 |
#3 | interdiff.txt | 2.76 KB | sun |
#3 | test.phpunit-boot.3.patch | 4.63 KB | sun |
#1 | test.phpunit-boot.1.patch | 7.39 KB | sun |
Comments
Comment #1
sunComment #2
andypostnot sure route name is passed...
also '@' check_plain() is removed, are you sure that all data secure?
why this is used?
Comment #3
sunReverted change to SpecialAttributesRouteSubscriber. (@Crell raised concerns in IRC.)
Comment #4
sunFWIW, there happens to be an existing issue for the changes reverted in #3: #2051877: Log error when people use invalid route parameters
Comment #5
sun#2.2 is indeed the only difference between the current PHPUnit bootstrap.php in HEAD and TestDiscovery. Trying to dissect the situation for myself, and verbosely:
TestDiscovery
retrieves the list of available extensions fromExtensionDiscovery
, which scans in the current (single) site directory only. (by default,/sites/default
)The current bootstrap.php scans the
/sites
directory itself for site subdirectories, and includes extensions from all site directories.I'm not sure how to address that yet, and also, whether we need to address it in the first place. Running tests from all site directories may work for pure unit tests, but as soon as we're going to run web/acceptance/BDD tests via PHPUnit, Drupal core's multi-site path discovery will kick in → A module located in a site-specific directory cannot be installed in the test, because it is not found to begin with.
run-tests.sh
resolves that issue via the--url
command line option, which causes the script to create a fakeRequest
for the specified base URL, which in turn is used to discover the site-specific directory. If--url
is omitted, then/sites/default
is used (but web tests will not work, unless Drupal is served directly onhttp://localhost
).I just performed a quick test, and it appears to be possible to pass custom options to
phpunit
without causing it to break. A value that follows a long option (e.g.,--url http://...
) seems to be interpreted as the option's value and not as a separate argument to phpunit itself.So theoretically, it might be possible to re-implement the site directory negotiation for phpunit. Whether that's a good idea is a different question, of course.
Comment #6
tstoecklerMaybe not as part of this issue, but this hints to me that that class should be in \Drupal\Core.
Patch itself looks good.
Comment #7
Mile23An OOP solution would be better of course. A solution that all systems could leverage would be ideal.
You mean DrupalKernel::getSitePath() of course. :-)
That is, soon this bootstrap script will require a kernel object with a container.
Which is bad.
Really \Drupal\Tests, which means SimpleTest can't get it. :-) That's one reason this script is lean and mean and functional.
Comment #8
Mile23So
Drupal\Core\Extension\ExtensionDiscovery
has reduced its dependencies, and you can (almost) inject the site path (see: #2605654: Modify Drupal\Core\Extension\ExtensionDiscovery to allow for scanning multiple file systems, enabling vfsStream testing).Here are two patches:
The small one is a POC and changes
core/tests/bootstrap.php
to useExtensionDiscovery
. It will fail, becausecore/includes/bootstrap.inc
is a dependency ofExtensionDiscovery
, and many tests make stub definitions of functions declared inbootstrap.inc
, so there will be errors. Also there are failures related to the issue linked above.The large one changes many of these tests and their code in order to make some of them pass. This is a WIP. It touches a lot of code, so it might not be RC-able, but it should be. It includes the changes in #2605654: Modify Drupal\Core\Extension\ExtensionDiscovery to allow for scanning multiple file systems, enabling vfsStream testing patch #2, so a re-roll might be necessary at some point.
In my opinion this issue is a bug report, because we had false passes on a number of tests before making this change in dependencies. The best example of this is
UpdateRegistryTest
which uses vfsStream to mock a whole Drupal filesystem. If you run the test in isolation, ExtensionDiscovery only runs once, which hides its static problems.Comment #12
Mile23After #2499239: Use test suite classes to discover different test types under phpunit, allow contrib harmony with run-tests I'm calling this CWF, since the new behavior for the phpunit tool is to use
TestDiscovery::scanDirectory()
to find tests per testsuite. (This issue was originally about usingTestDiscovery
inbootstrap.php
.)bootstrap.php
still uses its own functions to discover extensions, which is fine because we want to be able to testExtensionDiscovery
in isolation.As always: Re-open if you disagree.