-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Tests: Add new assertEqualHTML assertion
#8882
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
Conversation
assertEqualMarkup assertion
…encies_Scripts" This reverts commit c01a3c1.
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
The generated HTML produces async="async" or defer="defer". Match this in the expected HTML.
|
I've pushed some changes to completely remove the previous The work discovered at least one bug in the tests where the previous implementation "normalized" the output and forced the markup to appear equivalent when, in face, it was not. In this case, it purported to test html5 script behavior, but did not set html5 theme support. wordpress-develop/tests/phpunit/tests/dependencies/scripts.php Lines 1531 to 1534 in b0df96a
There are a number of changes where It's clear that this implementation of There's a conversation to be had around HTML5 support and whether the non HTML5 behaviors even make sense today, but that's beyond the scope of this PR. |
| $expected .= "<script type=\"text/javascript\" src=\"http://example.com\" id=\"test-example-js\"></script>\n"; | ||
| $expected .= "<script type=\"text/javascript\" id=\"test-example-js-after\">\n/* <![CDATA[ */\nconsole.log(\"after\");\n/* ]]> */\n</script>\n"; |
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 are a few cases like this where the contents of an (IE conditional) HTML comment were changed.
These script tags, on their own, would be recognized as equivalent with double " or single ' quotes. But they're not script tags, they are the text contents of an HTML comment where ' is not the same as ".
|
All of the tests here for IE conditional comments also seem quite out of place in today's internet. |
sirreal
left a comment
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 left some feedback but I think this is great and ready to go for the most part. It becomes much easier and less error prone to compare HTML.
It's worth mentioning that the tree builder functionality is largely duplicated from existing html5lib tests used for the HTML API. It's already seen significant usage, although the block parsing is new.
| private static function build_tree_representation( ?string $fragment_context, string $html ) { |
Co-authored-by: Jon Surrell <sirreal@users.noreply.github.com>
Co-authored-by: Jon Surrell <sirreal@users.noreply.github.com>
@sirreal Think it's worth doing a follow-up to share code between the two? |
assertEqualBlockMarkup assertionassertEqualHTML assertion
|
I only mentioned it because it seemed relevant for other reviewers. We could try out the sharing but I don't think it's necessary. |
Proposed changes
Add
assertEqualHTMLmethod toWP_UnitTestClassfor tests comparing HTML (potentially including block markup).Comparing HTML markup can be error prone and fragile. Typically we're interested in semantically equivalent HTML, which is what this assertion allows for; i.e. it has built-in tolerance for different attribute and class name order.
Internally, it builds a deterministic tree string representation of the HTML (using the HTML API) and compares the results.
The format of the tree is inspired by the HTML5lib-tests tree format.. It is extended with a special representation of block delimiters and their attributes.
This format also makes it easier to visually spot the differences between the two strings of HTML markup, as reported by the assertion. Quoting the inline documentation (PHPDoc) that's part of this PR:
Note
Edit: Fixed by @sirreal, see #8882 (comment).
This PR adds the newassertEqualBlockMarkupmethod to theWP_UnitTestCaseclass. Note thatclass Tests_Dependencies_Scripts, which is a subclass ofWP_UnitTestCase, already contains aprotectedmethod namedassertEqualMarkup. The latter is exclusively used for dependencies/scripts tests. The newassertEqualBlockMarkupcannot be used as a drop-in replacement, due to some differences in what it considers semantically equivalent HTML.The existence of that protectedassertEqualMarkupmethod was a consideration in naming the new methodassertEqualBlockMarkup, so that it wouldn't collide. It seems like a reasonable choice, given thatassertEqualBlockMarkupis indeed capable not only of parsing HTML, but also block markup.In a future iteration, we might choose to retire the existingassertEqualMarkupmethod (and useassertEqualBlockMarkupfor dependencies/scripts tests). This would then also pave the way for a general-purposeassertEqualMarkupmethod (which is able to parse HTML but agnostic of block markup), should the need arise.Props @sirreal @dmsnell
Trac ticket: https://core.trac.wordpress.org/ticket/63527
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.