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
As title
Proposed resolution
Recommended regex for searching: assert\w+\(.+instanceof.+\)
Example:
- $this->assertTrue($property instanceof StringInterface, 'Got the right wrapper fo the page.front property.');
+ $this->assertInstanceOf(StringInterface::class, $property, 'Got the right wrapper fo the page.front property.');
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#29 | interdiff.3128905.28-29.txt | 5.5 KB | longwave |
#29 | 3128905-29.patch | 182.53 KB | longwave |
#28 | 3128905-28.patch | 177.03 KB | longwave |
#19 | 3128905-19.patch | 177.81 KB | jungle |
Comments
Comment #2
jungleassertNotInstanceOf
Comment #3
jungle$this->assertTrue($entity instanceof EntityTest && $entity->getEntityTypeId() === $expected_entity_type_id);
$this->assertTrue($output instanceof MarkupInterface || is_string($output), new FormattableMarkup('\Drupal::theme() returns an object that implements MarkupInterface or a string for data type @type.', ['@type' => $type]));
$this->assertTrue(!isset($value) || is_scalar($value) || $value instanceof EntityInterface, $entity_type . ": Value $value_name of item $delta of field $name is a primitive or an entity.");
BTW,
assert\w+\(.+instanceof.+\)
matches the above 3 onesComment #4
longwave#3.1 could be split into two separate assertions? The other ones can't due to the use of OR operator as far as I can see.
Comment #5
jungleGood point! Thank you @longwave!
Comment #6
jungleOh, no, the order should be reversed
Comment #7
jungleComment #8
Kristen PolComment #9
Kristen PolThanks for the patch. Wow! Lots of changes... almost 700 lines o_O.
1) I went through every change and looked for:
2) I didn't see anything "wrong" per se, but noticed a couple things:
a) Some have text messages and some do not. If there was a desire to standardize on this for this assert, then this would be the time to do it.
b) For the two with
$group
in the old code, why pass inNULL
instead of not including the argument? See below.3) Patch applies cleanly.
4) Tests pass so I'm inclined to RTBC but am curious about thoughts on 2b above first.
Comment #10
Kristen PolI grepped the 9.1 dev codebase after applying the patch and found some stragglers for
assertTrue
that could be addressed so marking this back to "Needs work". Please review comments above as well. Thanks.Comment #11
longwaveThanks @jungle for the original patch and @Kristen Pol for the review!
Re #9.2b I agree that $group should be removed and have done so in this patch. I also wonder if we should refactor away
assertTwigTemplate
entirely as it is only called three times but that is perhaps out of scope as this patch is already quite big.Re #10.2 and #10.4 I have fixed these in this patch but #10.1 and #10.3 cannot be refactored due to the OR operator, there is no way of saying assertInstanceOf() with multiple types (or scalar types) as far as I know.
Re #9.2a I think we probably could remove *some* of the messages in this patch, e.g. the ones in TwigNamespaceTest seem helpful, whereas the one HandlerAllTest does not. Removing them all seems a step too far and probably needs separate discussion perhaps in a followup? There is also a separate argument for removing FormattableMarkup from the messages we do want to keep, but that is definitely out of scope here.
Comment #12
Kristen PolComment #13
Kristen PolThanks for the update!
1) The changes look good and address items in #9.2b, #10.2, and #10.4. I agree that #10.1 and #10.3 can't be addressed with the same approach because of the OR logic.
2) Re #9.2a, I don't have strong opinions on whether any messages should be added or remove in this patch... only that if that should be cleaned up, it might be good to do it in this patch... though I can see the argument that they be handled on their own.
3) Patch applied cleanly to 9.1 dev and included the 2 new files:
4) Checking the code after the patch is applied, we're just left with the two that won't be changed from #10.1 and #10.3:
5) Given all the above, if tests pass, then I'd mark this RTBC.
Comment #14
longwaveSpotted a number of
assert(... instanceof ...)
in tests, which I think are missing a call to $this? Should we fix these here?Comment #15
Kristen PolRight. I did notice that before but then made the assumption that only the
assertTrue
/assertFalse
were supposed to be handled. If those need to be updated, I'd vote for doing it here.Comment #16
mondrake#14 it's not clear why assert() is being used in tests, honestly. AFAIK it should be used in runtime code and 'switched off' from productiive execution via php.ini settings. I just git blamed the last from the list in #14 and it was introduced with #3039026: Deprecate file_directory_temp() and move to FileSystem service.
IMHO we should deal with #14 separately so that if anyone sees a reason to have that in tests, that discussion wouldn't hold this cleanup here.
Comment #17
longwaveLooking more closely I agree that we should move #14 to a possible followup, some of them look to be valid runtime assertions - but not all - so discussion would be needed.
Comment #18
catchLooks good but needs a reroll. By the way +1 to doing one assertion type at a time, good way to split these up.
The assert() from #14 are definitely out of scope here - I assume they were added for an easier time debugging failing tests, but either way should be a separate issue.
Comment #19
jungleRerolled from #11
Comment #20
mondrake@jungle if you just reroll resolving patch conflicts without adding additional code, I've seen it's OK and accepted by committers when you just say so in the comment and set back directly to RTBC.
Comment #21
jungle@mondrake! Thanks for your explanation! I am strictly following the rule that never ever RTBC my own patch(es) :p!
Background:
The original comments: see 3128814 #8 - #12
Comment #22
mondrake#21 I think it's more a matter of trust in cases like this... so no strict rules. But maybe @catch can provide his view. Would be good to know anyway. Thx
Comment #25
catchGenerally I don't count re-RTBCs as self-RTBCing if it's a re-roll for something small.
If it's a pure re-roll definitely OK. If it's fixing a typo or small coding style issue, usually OK (good to have an interdiff for transparency).
Also if you worked on a patch, someone else RTBCs it, there's some changes implemented by someone else, then you RTBC those changes, this is usually OK but it needs some judgement - i.e. the more people involved in an issue and the older it is, the more distributed the responsibility.
Committed/pushed to 9.1.x and cherry-picked to 9.0.x, thanks!
Comment #26
mondrakeFiled #3130811: Remove redundant $message from assert(Not)InstanceOf calls as a possible follow up. See you there.
Comment #27
longwaveThis should probably go back to 8.9.x if we are also to backport #3130811: Remove redundant $message from assert(Not)InstanceOf calls
Comment #28
longwaveQuick attempt at a backport, there might be some more calls we can do here.
Comment #29
longwaveFound some more in tests that have been removed or refactored in 9.0.x.
Comment #30
mondrakeSo this D8.9 overall is going to be covered combined in #3130811-19: Remove redundant $message from assert(Not)InstanceOf calls, so marking this back to fixed.
Comment #31
jungleThanks, @catch for your clarification/explanation. Commented back to 3128814 to let @dww know that I might break my oath of Never ever RTBC my own patch(es), strictly.