New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build/Test Tools: Replace some instances of assertEquals()
.
#1768
base: trunk
Are you sure you want to change the base?
Conversation
8c9ce7d
to
118e6d5
Compare
b71a904
to
b9b3068
Compare
assertEquals()
with assertSame()
.assertEquals()
.
084e6b7
to
5474772
Compare
95f348f
to
abfa900
Compare
This new assertion (introduced in this PR) is unnecessary. `assertArrayEquals()` does more testing and has the same result.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've separated out a subset of these changes in #3413. These are the more straightforward ones where types are more apparent and don't require much digging. Also looking for clarification on a few things.
@@ -1101,6 +1101,31 @@ public function assertQueryTrue( ...$prop ) { | |||
} | |||
} | |||
|
|||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain why this method is required? What does this accomplish that native PHPUnit assertions do not? And why is assertEquals()
OK in this context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functionally, nothing. However, every release, we sift through potentially hundreds of assertEquals()
to use stricter assertions instead. By having a clearly named wrapper, we can reduce workload each release. In addition, assertSimilarObject()
makes it clear what is being tested for those reading a test method, whereas assertEquals()
is just too ambiguous.
While this isn't required, there was some support for implementing this wrapper method to make life easier going forward. I'll drop a link to this in a bit.
In terms of why assertEquals()
is appropriate here, assertSame()
can't be used for objects, as their IDs are different and the assertion will always fail. assertObjectEquals()
is only for value objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this comment and Sergey's reply.
The idea is that having the wrapper method would allow for the possibility of banning assertEquals()
in tests/phpunit/tests/
, to encourage stricter testing, as well as reducing our workload with each release (such as this PR)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of having a linting check that fails if an occurrences of assertEquals()
are found in the tests. That's along what I had in mind.
It looks like there is assertEqualsCanonicalizing()
in PHPUnit (docs). But I'm not sure if this will work for all scenarios.
Could you take a look at that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There also may be shortcomings of that method that are not immediately apparent. So not saying we should switch these now without further discussion.
@@ -135,7 +135,7 @@ public function test_wp_update_comment_updates_user_id() { | |||
); | |||
|
|||
$comment = get_comment( $comment_id ); | |||
$this->assertEquals( 1, $comment->user_id ); | |||
$this->assertSame( '1', $comment->user_id ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Want to look at this one more. The property is documented as a string, but is set to a 0
integer by default.
@@ -262,7 +262,7 @@ public function test_wp_set_term_objects_finds_term_name_with_special_characters | |||
$post_id = self::$post_ids[0]; | |||
$expected = wp_set_object_terms( $post_id, $name, 'category', false ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is weird. It's setting expected and actual to the exact same thing. Not sure why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... that is weird.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah!
wp_set_object_terms()
creates a new term when an existing one isn't found. It then returns an array of affected term IDs.$expected = wp_set_object_terms( ... )
should create the term, and$actual = wp_set_object_terms( ... )
should find the existing term, with both returning an array of the same term.- If
$expected !== $actual
, then$actual = wp_set_object_terms( ... )
didn't find the existing term, and instead created a new one -> Failure.
@@ -188,8 +188,6 @@ public function test_handle_render_partials_request_for_non_rendering_partial() | |||
) | |||
); | |||
|
|||
$count_customize_render_partials_before = has_action( 'customize_render_partials_before' ); | |||
$count_customize_render_partials_after = has_action( 'customize_render_partials_after' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these tests adding 1 were working, but not checking what was originally intended. I think these changes are correct. But wanted to note what was going on for future reference.
By default, Core does not attach anything to customize_render_partials_before
or customize_render_partials_after
. So has_action()
was returning false
. Performing false + 1
below changed the value to 1
, and then it was being loosely compared to true
(and passing).
This PR replaces
assertEquals()
with more appropriate, stricter assertions where possible and without making any changes to source.For easier reviewing, commits have been separated based on the replacement assertion and any additional changes required to implement the stricter assertion.
Trac ticket: https://core.trac.wordpress.org/ticket/60706
Trac ticket: https://core.trac.wordpress.org/ticket/59655
Trac ticket: https://core.trac.wordpress.org/ticket/55654
Trac ticket: https://core.trac.wordpress.org/ticket/54726