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.
Problem/Motivation
The Drupal\system\Tests\Module\ClassLoaderTest should test if a class provided by a module could not be loaded if the module is disabled. But that test doesn't work the way it is implemented. The route that is accessed by this web test is not available because the module providing it is not installed. The resulting 404 is erroneously taken as successful check that the class loader was prevented to load a class of a disabled module.
Proposed resolution
Fix the test. Done.
Remaining tasks
none
User interface changes
none
API changes
none
Data model changes
none
Comment | File | Size | Author |
---|---|---|---|
#22 | 2777651_fixed_test.patch | 2.13 KB | mkalkbrenner |
#4 | 2777651_fixed_test.patch | 2.13 KB | mkalkbrenner |
#2 | 2777651_failing_test.patch | 1010 bytes | mkalkbrenner |
Comments
Comment #2
mkalkbrennerHere's a the "corrected" failing test.
Comment #4
mkalkbrennerComment #5
mkalkbrennerNow we have the existing tests fixed in #4.
But the tests states that auto loading of classes provided by a non enabled module should not be possible!
Here's a demonstration that there's no protection like this (that affected us in search_api).
Comment #6
mkalkbrenner.
Comment #7
mkalkbrennerThe interdiff between #4 and #5.
Comment #9
mkalkbrennerOK, understood the reason why the patch in #5 fails and why classloading has to be implemented as web test.
SomeClass is provided by a test module and drupal_phpunit_get_extension_namespaces() registers all test modules' paths for the PSR4 classloader.
So the patch in #4 is correct and should be committed to have some test coverage that classes provided by disabled modules are not auto loadable.
Comment #10
mkalkbrennerComment #11
cspitzlayLooks good to me.
Comment #12
cspitzlayUpdated the issue summary
Comment #13
cspitzlayComment #14
catchThis is still in progress and there's no passing patch yet, so should not be RTBC. Interesting find in the issue though.
Comment #15
cspitzlayAs stated in #9 the patch from #4 contains the correct fix to the broken test and it did pass.
The expectation that the classloading in #5 should not work is wrong as the test is done in the test process itself where classloading works differently because phpunit interferes.
What is missing for this issue to be RTBC?
Comment #16
mkalkbrennerThe patch in #4 should be committed as reviewed by cspitzlay. It passes and fixes the existing test.
In #9 I answered the question I asked myself in #7. If we consider drupal_phpunit_get_extension_namespaces() to be a bad implementation in general, we should open a follow-up issue. BTW personally I think that it is a bad thing that class loading behaves different in a Kernel Test.
Please excuse the confusion I potentially created with #7.
Comment #17
alexpott@mkalkbrenner so test class autoloading is a bit of a controversial subject but I'm inclined to agree that running tests should not affect the autoloader in anyway. In my mind autoloaded tests are completely wrong-headed because you never autoload a tests at runtime and by being able to autoload tests you are affecting the system under test.
The tests added here are an improvement. I would not say that the current tests are broken given that there should be no difference between a module that has been installed and then uninstalled and one that has never been installed.
Comment #18
alexpottAlso it helps committers a lot when the patch to commit is the final patch on the issue. And it helps testbot too because rtbc re-test only occurs on the final patch too.
Comment #20
xjm(Retitiling for clarity and setting the issue priority based on https://www.drupal.org/core/issue-priority#major).
Comment #21
xjmAh, and as stated above, please upload the RTBC patch as the final patch on the issue. (I got confused also.) Thanks!
Comment #22
mkalkbrennerThey are broken. The resulting 404 is erroneously taken as successful check that the class loader was prevented to load a class of a disabled module.
No problem. Here's the patch from #4 again.
Comment #23
penyaskitoI think it's safe to get this back to RTBC.
Comment #24
alexpottCommitted and pushed bd6b92d to 8.3.x and 3de07a9 to 8.2.x. Thanks!