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
Regex for searching: assert.+\(count\(.+\) (>=|<=) \d+\)
example:
- $this->assertTrue(count($cache_items) >= 2);
+ $this->assertGreaterThanOrEqual(2, count($cache_items));
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#68 | 3128815-68.patch | 72.57 KB | Spokje |
Comments
Comment #2
jungleRescope this to replace other missed similar usages when necessary, apart from #3126965: [backport] Replace assert* involving count() and an integer literal with assertCount(), #3128813: Replace assertEqual() or assertSame() on two calls to count() with assertCount() and #3128814: Replace assert* involving count() and an equality operator with assertCount()
Comment #3
dwwPer Slack thread with @jungle, I'm helping to give these issues human readable titles.
However, in this case, I'm not sure the proposed change is an improvement. ;) I think I'm -1 to this one. I don't see how this improves readability at all, and it takes a lot more characters to make it work...
Also, it's not clear why we care about
count()
here at all. Seems like the intention would be to replace:assertTrue(foo >= bar)
withassertGreaterThanOrEqual(foo, bar)
, regardless of what foo and bar are...Comment #4
jungleFor readability, agree with @dww. +1 to close this
Comment #5
jungleClosing this as assertGreaterThanOrEqual does not have better readability
Comment #6
jungleComment #7
mondrakeI am reopening this since I think we should also consider the output in case of failure.
Taking example from #3, in case of failing assertion
::assertTrue($foo >= $bar);
will produce an error like the following, not very helpful IMHO
OTOH, in case of failure of
::assertGreaterThanOrEqual($foo, $bar);
the message will be far more readable, plus the types of $bar and $foo will be automatically checked by PHPUnit to ensure they are comparable
Comment #8
jungleGood point! +1 to #7!
Comment #9
jungleOne usage found so far.
Comment #10
mondrakeI would suggest a much broader scope,
$ grep -Er '>assert(True|False).*( > | < | <= | >= )' .
EDIT - let's agree it makes sense before attacking the code
Comment #11
jungle@mondrake, thanks for your proposal! I am happy with the new scope, as the current scope almost means nothing to do. So +1 to #10.
Comment #12
mondrakeWorking on this, with regex
>assert(Not)?(Tr|Fa|Eq|Id).*( < | > | >= | <= )
Comment #13
mondrakeNot really sure so testing a patch so far.
Comment #14
longwaveUnsure if you wanted reviews yet but I have a few comments here:
The message seems useful here.
I think this is equivalent to and more readable as
assertNotEmpty()
- although doesUuid::isValid('')
return TRUE?Comment says > but test says >= !
This could be
assertNotEmpty()
?Comment #15
mondrakeThanks @longwave. I will take this in next patch.
Comment #16
mondrakeOnly addressing failures in #13 to get to a clear reference for conversion further along, and #14.
#14:
1. OK done
2. Yes, that seems redundant but not sure we can remove it here
3. OK, corrected the comments that seemed wrong to me
4. Not IMHO - id() should return a number that is a sequence from a serial column db table, so I suggest to keep
Comment #17
mondrakeIf this passes, it's up for review.
Comment #18
mondrakeComment #19
mondrakeComment #20
jungleSorry, :p
Comment #21
mondrakeThank you, @jungle
Comment #22
mondrakeComment #23
longwaveI checked each of the changes and they all look fine to me.
Good spot, this never could have failed before :)
Comment #24
xjmReviewing.
Comment #25
xjmThanks! I like where this is heading. My main concern is that there are a few places where the assertion message is adding information about how the test works that's lost when we remove it. A lot of these will end up with failure messages that are like "Failed asserting that 3 is greater than 5"... which is useful debugging as far as it goes, but the test at that line should explain why we care about the relative values of 3 and 5.
We can retain the information where it's useful by adding an inline comment that explains the purpose of the assertion, while still getting the raw debug values from the assertion.
Here we're losing information provided by the assertion messages. Can we move them to inline comments above the respective assertions?
// Verify that... (etc.).
This is a weird assertion to begin with.
I confirmed there's still another
FormattableMarkup
in there, which is why theuse
statement stays.(Nothing actionable, just making note because I gave it consideration.)
Other places where the assertion message contains potentially useful info we could move to an inline comment.
The previous message isn't great, but it at least hints at the point of the order being altered by... whatever.
Comment #26
xjmComment #27
xjm(Saving issue credit.)
Comment #28
xjmI'd suggest we split this into two scopes: First, take care of the assertions that already don't have assertion messsages; then, handle the cases where we're removing the assertion messages (since those may provide documentation value and need to be reviewed differently).
Comment #29
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedWorking on this.
Comment #30
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedPatch re-rolled and addressed the second part of the scope of this ticket as suggested in #28.
Also includes #25.1, #25.3, #25.4
Comment #31
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedComment #32
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedComment #33
shobhit_juyal CreditAttribution: shobhit_juyal as a volunteer and at Srijan | A Material+ Company commentedHi,
I've reviewed the patches and got some suggestions:
Comment's first letter should in capital and a fullstop is expected at the end.
Comment #34
shobhit_juyal CreditAttribution: shobhit_juyal as a volunteer and at Srijan | A Material+ Company commentedSorry, I just missed the diff and reviwed wrongly.
The patch is fine, moving it to RTBC
Comment #35
xjmNice work! That helps keep the debugging information in the tests, without obscuring the actual results of the assertions.
We need some small cleanup on many of the comments, mostly to do with comments wrapping too early or late, or with some small grammar fixes now that the phrases of the assertion messages are whole sentences as inline comments.
We need to add the word "the" now that this is a sentence:
"Verify that the BigPipe start signal appears before the stop signal."
These comments are over 80 characters and need to be wrapped.
We've had issues to clean this up before, but "ID" should be capitalized when it's used in a sentence. Lowercase "id" is a concept in psychology.
The assertion messages already got this wrong, but since we're upgrading some of these from sentence fragments to actual comment sentences, we can capitalize it in all cases in the new comments.
Also, we should say "Verify that the revision ID is greater than the article ID." (Since it's a sentence now.)
"the site UUID"
Conversely, these are wrapping too early.
Also, I think it should be:
(We don't need the extra words.)
And, "the 'BBB Update test' project".
"the order of the view mode"
...That said, an invdividual item doesn't have an order; it has a position. Maybe let's move the comment outside the
foreach
and say "Verify that the view modes are in the correct order on the page.""Verify that the new file was saved".
"a new file ID"
"the new file size"
"the timestamp"
"the image"
"that the rollback explanatory error was logged"
"Verify that this revision's ID is greater than the default revision's ID."
Aside: That's adorable!
There should be a comma before "we".
"the teaser"
"from the string."
"the revision ID".
"the maximum line length"
Also, the
$
is missing from$maximum_line_length
."the System/User module version" (Note the capitalization as well, since module names are proper nouns.)
This is wrong in the assertion message, too, but "has passed" rather than "is passed".
"the action definitions"
"the term"
"Verify that the creation time is correct."
I think we don't need these comments; the inline comments above the hunks are sufficient.
"that a JavaScript file is rendered before jQuery."
"Verify that JavaScript weight is correctly altered by the alter hook."
"the created time"
"Verify that the results are returned in the correct order".
Also, I think this is another case where we can move the comment outside the
foreach
.Wrong comment. :)
This is wrong in the original assertion message as well, but "Verify that the transaction depth increases with a new transaction."
"JSON-encoded"
"from the cache."
A lot of bullets, but all small fixes. :) Thanks!
Comment #36
jungleThanks @xjm, on it.
Comment #37
jungleA missing raw-interdiff.txt for the patch in #30
Comment #38
jungleAddressing #35
#35.3
> Also, we should say "Verify that the revision ID is greater than the article ID." (Since it's a sentence now.)
Correcting over correction :p, changed to "Verify that the revision ID is greater than the default revision ID."
Changed to
Verify that the results returned in correct order.
, but it does not eligible moving out theforeach
loop, to me. As the following line is$this->assertNotEqual($record->$name_field, 'Ringo', 'Taskless person not selected.');
Continue self-reviewing next.
Comment #39
jungleForgot to upload the patch.
Comment #40
jungleA few changes made, See interdiff.
Comment #41
mondrakeThanks. Looks great to the eyes of a non-English-native human being. :)
Comment #42
xjmThanks @jungle and @mondrake. A few more "the" need to be added. (English articles... they're everywhere, like insects.)
Missing the second "the" ("before the stop signal").
"the translation creation timestamp"
"the translatable created field"
"Verify that the order of the view modes is correct on the page."
I think for these two we could combine it and just say "Verify that the image was scaled to the correct width and height" above the hunk.
Similarly here, "Verify that the timestamp and last checked fields were both updated."
We can group these too; "Verify that the translation of contrib_module_one is imported and updated.
"a specific theme call"
Oops, the word "correct" is repeated. It should be merely "Verify that the creation time is correct."
I think we can omit this comment; the comment above is sufficient.
All of these should be "Verify that the results are returned in the correct order."
A few more to move outside their loops.
"the new revision"
Actually "in" also doesn't make sense; I would say:
"Verify that the saved translation for the new translation has a newer revision ID."
Comment #43
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedOn it.
Comment #44
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedAddressing #42.
@xjm, I have gone through all your review points and updated the patch accordingly.
Thanks!
Comment #45
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedComment #46
jungleOver 80 chars
Comment #47
jungleComment #48
dwwGetting very close, thanks!
// Verify that the feed items were created.
;)
Now that this is a comment, '$site_uuid' doesn't tell us anything. We just said "site UUID".
// Verify that the site UUID is valid.
Maybe out of scope, but this seems clearer:
// The test is only valid if the field cardinality is greater than 1.
$this->assertGreaterThan(1, $cardinality);
// Verify that the new file got saved.
Yikes, buggy assertion. Glad to see this getting fixed here. I had to double-take, but confirming this is correct.
...the translation...
I think we can kill this comment, since it's just an English translation of the assertion, without any added context or information.
A) "translations" shouldn't be plural here. If it should be plural for some reason, we need "do not" not "does not".
B) Although we haven't formally resolved #3131946: [META] [policy] Remove PHPUnit assertion messages when possible, and standardize remaining messages (ping/bump), the emerging consensus is that "negative" assertion messages like this are confusing and weird, and we should use something like:
"The Spanish translation should appear before the French one on $message."
Given the previous 2 lines of context, I don't think the new comment here adds anything.
Same here.
Uhh, that's not what the assertion is testing. Or at least, that's a really confusing comment.
Where's 1000 coming from? That's what this comment should explain.
// Verify that the maximum line length found was less than or equal to [whatever it is that makes us assert 1000 here].
Given context, I don't think either of these new comments are needed/helpful.
Not sure why we're adding this comment here. Seems out of scope (and unneeded).
In #35.5, @xjm complained this wasn't wrapped properly. However, given 'CCC Update test' as a distinct thing, maybe this is fine not to wrap the "'CCC" part to the previous line. +1 for keeping this as-is...
Probably out of scope, but it'd be even more helpful to explain why "- 20" here. ;)
If we're going to change this message, let's do:
"'name' field weight ($name_weight) should be smaller than 'pass' field weight ($pass_weight)."
Comment doesn't add anything.
Existing assertion bug, but per above, the 2nd here should be:
$this->assertLessThanOrEqual($current['title'], $prev['title']);
Given context, I don't think the comment adds anything.
This was an existing usage, but "monotone" seems wrong here. ;)
I think these want to say:
// Verify that the serial is monotonically increasing.
?
I could be totally off, but I've never heard of using "monotone" like this, and Google isn't turning up anything that contradicts me.
Seems fairly self-documenting, but if we're going to preserve a comment here, I'd keep the "minimum count" one, too.:
Existing weirdness, but if the message is "... increases", it'd be less cognitive dissonance to use:
$this->assertGreaterThan($depth, $depth2);
This message is weird:
A) "correctly" isn't grammatically correct. ;)
B) Again, we (or at least I *grin*) don't want "negative" assertions like this.
sprintf("Weight of vertex %s should be less than vertex %s.", $previous_vertex, $vertex)
Maybe this is cleaner?
?
Given context, I think we should remove the new comment and leave the original.
If we actually need to keep the new comment, it should wrap into the previous comment line.
Same here.
Thanks!
-Derek
Comment #49
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedComment #50
sja112 CreditAttribution: sja112 at Srijan | A Material+ Company for Drupal India Association commentedThanks, @dww for such a detailed review of the patch.
Addressing #48,
Except #48.14, #48.15 and #48.21 Patch includes all the recommended changes.
#48.14
No action was required.
#48.15
Not sure why "- 20". :P
#48.21
To avoid the addition of comment inside loop here, a single comment was added outside.
#48.24
As we want to ensure that the element was retrieved from the cache.
Thanks!
Comment #51
mondrakeComment #52
SpokjeDrive-by Hit-n-Run fixing of missing semi-colon.
Comment #54
SpokjePatch fails on #48.18:
Comment #55
shobhit_juyal CreditAttribution: shobhit_juyal as a volunteer and at Srijan | A Material+ Company commentedHi,
@Spokje, I can confirm your suggestions.
I think the comparison between the current and previous titles are not really required there. We can test the order and moreover we can also test for empty title.
Comment #56
mondrakeComment #57
mrinalini9 CreditAttribution: mrinalini9 at Srijan | A Material+ Company for Drupal India Association commentedRerolled patch #55, please review.
Comment #58
mondrakeComment #59
mondrakeComment #60
nikitagupta CreditAttribution: nikitagupta at Srijan | A Material+ Company for Drupal India Association commentedComment #61
nikitagupta CreditAttribution: nikitagupta at Srijan | A Material+ Company for Drupal India Association commentedReroll patch #55.
Comment #62
jameszhang023 CreditAttribution: jameszhang023 commentedThis patch only did a reroll operation, please review. Thanks
Comment #64
mondrakeReroll only.
Comment #65
longwaveAll review points have been addressed, this looks ready to go.
Comment #66
mondrakeComment #67
SpokjeRe-Rolling as we
speakComment #68
SpokjeReroll of #64
Comment #69
SpokjeSince this is a simple reroll: Back to RTBC as per #65
Comment #72
catchInitially was going to ask why some assertion custom messages were converted to comments and some left, but actually all the decisions look right to me - we show the raw comparison where the message wasn't adding anything, and then the custom messages that are left are explaining what's actually happening.
Committed/pushed to 9.2.x and cherry-picked to 9.1.x, thanks!