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
Part of the #1577902: [META] Remove all usages of drupal_static() & drupal_static_reset() effort for usages of drupal_static()
and drupal_static_reset()
in \Drupal\Tests\image\Functional\ImageEffectsTest
tests.
- Most of the methods from
ImageEffectsTest
are not doing any HTTP request. The exception is::testEffectFormValidationErrors()
but its scope could be tested with Kernel rather than Functional test. - No method from
ToolkitTest
is doing HTTP requests
.
Proposed resolution
- Convert
ImageEffectsTest
into a Kernel test. - Convert
ToolkitTest
into a Kernel test. - Deprecate
\Drupal\FunctionalTests\Image\ToolkitTestBase
. - Add a new trait
\Drupal\Tests\Traits\Core\ToolkitTestTrait
to provide reusable code.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
N/A
Comment | File | Size | Author |
---|---|---|---|
#70 | 3035518-69.interdiff.txt | 761 bytes | claudiu.cristea |
#69 | 3035518-69.patch | 29.94 KB | claudiu.cristea |
#68 | 3035518-68-8.9.x.patch | 29.94 KB | claudiu.cristea |
#62 | 3035518-61-20percent.txt | 26.04 KB | mondrake |
#62 | interdiff_52-61.txt | 7.83 KB | mondrake |
Comments
Comment #2
claudiu.cristeaHere, I started by converting
testImageEffectsCaching()
as this would satisfy #1577902: [META] Remove all usages of drupal_static() & drupal_static_reset() .Comment #3
claudiu.cristeaTitle fixing.
Comment #5
claudiu.cristeaExpanded the scope to cover also
\Drupal\FunctionalTests\Image\ToolkitTest
.Comment #6
claudiu.cristeaComment #7
claudiu.cristeaComment #8
dwwMostly looks good. Definitely +1 to Kernel-ifying these if possible. :)
Disclaimers:
- This is my first time ever looking at any of these particular tests.
- I didn't closely verify that all the functions that got moved around are exact replicas, nothing got lost, etc. I assume it's cool, but a closer review would be great before RTBC.
Some questions/concerns/nits:
Would love to see
$image_module_test_counter
declared explicitly, with a very clear phpDoc comment about it, why it's a raw global like this,@see
to where it's used, etc."The ...\ToolKitTestBase class is deprecated...".
Also, should we mention
ToolkitTestTrait
here as a partial replacement?Same here: mention the new Trait?
Seems like this should say it's got
\Drupal::state()
dependencies so no one tries to use it in a Unit test, right?In fact, seems like it depends on the image_test module being enabled, too, right? I'm only inferring that from reading this patch.
Comment #9
claudiu.cristea@dww, thank you for review.
#8.1, 2, 3: Fixed.
#8.4: That is a very good point. I moved the trait under the Kernel tests namespace and stated in the docblock that is designed for kernel tests.
Comment #10
claudiu.cristeaComment #11
andypostNice idea, just needs more polishing
instead of new global makes sense to use state service as other tests doing
todos needs follow-up issue link
s/Test/Tests
I bet that this manager could be a protected variable instantiated in setUp()
Comment #12
dww#11.1 is a much better solution to #8.1, thanks! :)
+1 to the rest of #11, too.
Cheers,
-Derek
Comment #14
claudiu.cristeaThank you, @andypost,
True, #11.1 is a far more better solution.
#11.2: Added #3040887: Improve and add missed scenarios in ImageEffectsTest.
#11.3, 4: Fixed.
Comment #15
andypost@claudiu.cristea looks you're mixed patch & interdiff from locale module
Comment #16
claudiu.cristea@andypost :)
Comment #17
claudiu.cristeaYeah, sorry.
Comment #18
claudiu.cristeaComment #19
claudiu.cristeaComment #20
kim.pepperCan this be a kerneltest too? Or maybe https://www.previousnext.com.au/blog/drupal-8-ftw-it-test-or-it-form-act...
We can get this from $this->container->get()
We can get this from $this->container->get(). Possibly in setUp() ?
We can do assert($toolkit instanceof ImageToolkitInterface) instead.
Comment #21
claudiu.cristea#11.1:
No, unfortunately. That test tests a core form. A kernel test implements
FormInterface
and provides its own form only for testing purposes. But in this case we test a specific form. Mocking theImageEffectEditForm
in the test would be too much as that might change in the future and it gives me the feeling the we would mock too much. This should stay as a functional test.#11.2: Fixed.
#11.3: Fixed but kept as local variable as the other tests doesn't require the state service.
#11.4:: Fixed.
Comment #22
claudiu.cristeaOK, finally addressed also #20.1.
This means that functional
ImageEffectsTest
is completely gone and I had to fix also the issue title, summary and the change notice.Comment #23
kim.pepperNice! LGTM
Comment #25
LendudeUnrelated fail
Comment #26
alexpottWe shouldn't be removing the use statement here - that'll break this test base class.
This is not the correct namespace for test traits. They can go in core/tests/Drupal/Tests/Traits/Core now - so let's add an Image directory in there and move this.
As this trait can be used by both kernel and functional tests this is probably better done with \Drupal at this point. It makes less assumptions about the properties of the class it is being used from.
Comment #27
claudiu.cristeaComment #28
claudiu.cristeaFixed remarks from #26.
Comment #29
claudiu.cristeaForgot the patch.
Comment #30
klausiLooks good to me, just some minor stuff we should fix:
This is a bit sad that we lose the nice messages. We can still pass them in the new phpunit methods, right? Can we just keep them?
Format is "@deprecated in drupal:8.8.0 and is removed from drupal:9.0.0.", see #3024461: Adopt consistent deprecation format for core and contrib deprecation messages. Same for the trigger_error(), should use the new format.
I'm a bit concerned that we are throwing away all the messages with the converted assertions. Yes, sometimes they are a bit redundant, but in other cases they give very useful insight what the assertion does/expects. Any reason why you removed them?
Comment #31
pguillard CreditAttribution: pguillard commentedI fixed the 2 minor stuff suggested at #30..
Comment #32
claudiu.cristea@klausi
There's a problem with keeping them. In Simpletest the assertion messages were described the SUCCESS of the assertion. Contrary, in PHPUnit, the message should describe the FAILURE. So, if we want to keep them we have to invert the logic in the message. Probably a good workaround, already used, would be to remove them from assertion but place them as a comment just above.
Comment #33
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation for Pfizer, Inc. commentedThis was RTBCed before, reviewed by @alexpott on #26, after which the concerns were addressed. Regarding the messages, I think the response on #32 is valid and is what we've been doing on other issues. So I think it's safe to go back to RTBC.
Comment #34
catchI think we should do claudiu's suggestion and convert these messages to comments. The assertions are not very self documenting by themselves given it relies on array index.
Comment #35
pguillard CreditAttribution: pguillard commentedI applied claudiu's suggestion, was my mistake by the way.
Comment #36
catchI think we need to convert most/all of the messages to comments though for example the messages above:
Are lost here. Really anything where we're asserting against array indexes should definitely be retained.
Comment #37
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation for Pfizer, Inc. commentedAppologies I was too hasty to set back to RTBC. Restoring all messages here as comments.
Comment #40
Hardik_Patel_12 CreditAttribution: Hardik_Patel_12 at QED42 for Drupal India Association commentedRe-rolling against 9.1.x-dev.
Comment #42
mrinalini9 CreditAttribution: mrinalini9 at Srijan | A Material+ Company for Drupal India Association commentedFixing test case failure issue in #40, please review.
Comment #43
klausiDrupal 9 was released, so we need to update the deprecation messages.
Why do we move the assertion messages to comments? We can leave them because assertEquals() has a message option as third parameter? I think having assertion messages is much better than comments because then you see them also in test output.
Comment #44
Hardik_Patel_12 CreditAttribution: Hardik_Patel_12 at QED42 for Drupal India Association commentedComment #45
ravi.shankar CreditAttribution: ravi.shankar at OpenSense Labs commentedHere I have updated the depreciation messages.
Comment #46
klausiThanks!
Can we also use the assertion messages instead of comments as I suggested in #43?
Comment #47
dwwRe: #43 / #46: See #3131946: [META] [policy] Remove PHPUnit assertion messages when possible, and standardize remaining messages -- not fully decided yet, but core is moving away from custom assertion messages when they add nothing over the default assertions from PHPUnit itself.
Comment #48
Hardik_Patel_12 CreditAttribution: Hardik_Patel_12 at QED42 for Drupal India Association commentedMoving back to Needs Review.
Comment #49
mondrakeIt's not finalised yet, but at least two core committers are positive about #3154762: [policy, no patch] All new Drupal 10 code should use appropriate type hints wherever possible, so I would suggest to start that. Also, see #3138078: [D9.3 beta - w/c Nov 8, 2021] Add a 'void' return typehint to custom assert* methods.
should have a
: void
return typehint, and $effect_name astring
typehint.It's for deprecation in 9.1.0 now, and we miss a deprecation test.
$this->assertTrue
$this->assertInstanceOf
should have a
: void
return typehint.should have a
: void
return typehint.should have an
: array
return typehint.should have an
: ImageInterface
return typehint.Comment #50
ridhimaabrol24 CreditAttribution: ridhimaabrol24 at Srijan | A Material+ Company for Drupal India Association commentedimplementing suggestions from #49
Comment #51
mondrakeshould be
$this->assertTrue($calls['apply'][0][1]['p2']);
should be
protected function getImage(): ImageInterface {
and ause
statement added at the top of the file with the fully qualified class nameComment #52
ridhimaabrol24 CreditAttribution: ridhimaabrol24 at Srijan | A Material+ Company for Drupal India Association commentedWorked on #51
Comment #53
mondrakeThanks
Comment #54
mondrakeA diff made using
git diff --cached 9.1.x -M20%
so to visually see what was changed from the functional version of the tests.Comment #55
alexpottThe assertImageEffect method is always followed by an assertToolkitOperationsCalled(). I think think the signature for assertImageEffect should be:
and it should call assertToolkitOperationsCalled() because without that call we're not really asserting the effect of processing an image effect plugin.
And also does this method belong on the trait? I think it might be useful for modules that provide an image effect.
This is not the correct format and doesn't have the correct versions.
{inheritdoc}
<3 the return typehinting. Nice to see on new stuff.
Comment #56
Deepak Goyal CreditAttribution: Deepak Goyal at Srijan | A Material+ Company for Drupal India Association commentedComment #57
Deepak Goyal CreditAttribution: Deepak Goyal at Srijan | A Material+ Company for Drupal India Association commentedHi @alexpott
Made changes please review.
Comment #58
alexpottWe need to change all the calls to this method to pass in the expected operations and we need to move the
$this->assertToolkitOperationsCalled($expected_operations)
inside this method.Also I suggested moving this to the trait as it looks helpful.
E_USER_DEPRECATED was correct. The message should be:
'The ' . __NAMESPACE__ . '\ToolkitTestBase class is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. . There is no replacement provided as functional test base class because toolkit operations should be tested as kernel tests. \Drupal\KernelTests\Core\Image\ToolkitTestTrait trait has been added to provide a similar functionality for toolkit kernel tests. See https://www.drupal.org/node/3035573.
This is not that see the documentation for assertToolkitOperationsCalled()
No fullstop.
Comment #59
alexpott@Deepak Goyal also when making changes to a test it is good practice to run the test before uploading a patch - if you'd done that you'll see that #57 is incomplete... you'll get lots of
Comment #60
mondrakeDo we need a test for the deprecation of
ToolkitTestBase
?Comment #61
ridhimaabrol24 CreditAttribution: ridhimaabrol24 at Srijan | A Material+ Company for Drupal India Association commentedHi
Made changes as suggested in #55 and #58.
Please review.
Comment #62
mondrake#55 looks addressed - #57 was way out of track, so here attaching an interdiff #52 -> #61 and again a patch with -M20% to see changes between functional and kernel.
#61 is RTBC for me.
EDIT - re. #60 I looked back at the 8.9.x branch and I could not find explicit tests for entirely deprecated base test classes.
Comment #63
alexpottCommitted bf94a9e and pushed to 9.1.x. Thanks!
Comment #66
claudiu.cristeaVery bad that this change was not backported to Drupal 8.9. We have a site transitioning from 8.9 to 9.2 and which runs a test extending ToolkitTestBase. So, in CI it runs on both 8.9 and 9.2. Now I need a lot of hocus-pocus to make it work.
Comment #67
claudiu.cristeaLet's try because of #66
Comment #68
claudiu.cristea8.9.x reroll
Comment #69
claudiu.cristeaComment #70
claudiu.cristeaThe interdiff
Comment #71
alexpott@claudiu.cristea this is very unlikely to land in Drupal 8.9.x - it would have to be a completely different patch that didn't remove the old code and kept testing it.
I think you're probably better of patching 8.9.x for you own needs or doing some hocus-pocus.
Comment #74
xjmDrupal 8 is very end-of-life, so restoring status against 9.1.x.
Comment #75
Hardik_Patel_12 CreditAttribution: Hardik_Patel_12 at Portage CyberTech commentedComment #77
quietone CreditAttribution: quietone at PreviousNext commentedPublish CR