Skip to content
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

Draft
wants to merge 24 commits into
base: trunk
Choose a base branch
from

Conversation

costdev
Copy link
Contributor

@costdev costdev commented Oct 19, 2021

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

@costdev costdev marked this pull request as ready for review October 19, 2021 04:58
@costdev costdev changed the base branch from master to trunk November 28, 2021 01:06
@costdev costdev force-pushed the #53364 branch 3 times, most recently from 8c9ce7d to 118e6d5 Compare November 28, 2021 01:18
@costdev costdev force-pushed the #53364 branch 2 times, most recently from b71a904 to b9b3068 Compare December 12, 2021 10:30
@costdev costdev changed the title Tests: Replace some instances of assertEquals() with assertSame(). Build/Test Tools: Replace some instances of assertEquals(). Dec 12, 2021
@costdev costdev marked this pull request as draft December 15, 2021 01:20
@costdev costdev force-pushed the #53364 branch 3 times, most recently from 084e6b7 to 5474772 Compare December 20, 2021 04:25
@costdev costdev force-pushed the #53364 branch 10 times, most recently from 95f348f to abfa900 Compare April 22, 2022 08:27
@hellofromtonya hellofromtonya self-requested a review May 2, 2022 15:21
desrosj added a commit to desrosj/wordpress-develop that referenced this pull request Oct 6, 2022
Copy link
Contributor

@desrosj desrosj left a 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.

tests/phpunit/includes/abstract-testcase.php Show resolved Hide resolved
@@ -1101,6 +1101,31 @@ public function assertQueryTrue( ...$prop ) {
}
}

/**
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

@costdev costdev Oct 6, 2022

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)

Copy link
Contributor

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?

Copy link
Contributor

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 );
Copy link
Contributor

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 );
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... that is weird.

Copy link
Contributor Author

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' );
Copy link
Contributor

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants