What problem does this address?
Currently, any change made to styles generated by class WP_Theme_JSON cause multiple tests from its test suite to fail, mostly due to diffs in CSS strings being checked for equality.
Adjustments to CSS output, whether properties or rule specificity, are very common, and test strings are incredibly painful to update when they inevitably fail.
The biggest culprits are the 30 or so tests that check the output of get_stylesheet. I think the main reason there are so many tests focusing on that function is that it brings together the output of a bunch of protected functions such as get_layout_styles, get_block_classes and get_css_variables, among others, and it's being used essentially to test the output of those functions.
What is your proposed solution?
How can this be improved?
I don't love the idea of tests comparing CSS strings, because the outcome of the test relies too much on implementation details (the exact shape of the CSS string, which the get_stylesheet function is not even responsible for). A possible alternative would be to check for the presence of one or another property or classname inside the string, instead of trying to match the whole string.
In general, unit tests are useful to check that the behaviour of a function remains unchanged after an edit or refactor. If we're testing an exact string of CSS, then all the changes we make to these functions will alter the output, because our styles are continually evolving. So what's the point of these unit tests? They're never catching any actual bugs. If we can abstract what we're checking for a bit - say we check that the function outputs a valid CSS string, but not its exact shape - maybe the tests become more useful while not being such a maintenance burden.
I'd love to hear about other potential approaches here!
Other things we can do to mitigate the impact of these tests on developer experience:
- Test output of functions called by
get_stylesheet independently.
- Use a minimal set of properties for each test, so the test strings are smaller and easier to update when they inevitably change.
Further improvements for class WP_Theme_JSON itself:
- Look into removing the custom CSS-specific functions in favour of using the general global styles ones, as per this comment.
- There's a
get_svg_filters function that isn't being used anywhere in either core or gutenberg, should we deprecate it? A quick check in https://www.wpdirectory.net/ doesn't show any use either.
What problem does this address?
Currently, any change made to styles generated by
class WP_Theme_JSONcause multiple tests from its test suite to fail, mostly due to diffs in CSS strings being checked for equality.Adjustments to CSS output, whether properties or rule specificity, are very common, and test strings are incredibly painful to update when they inevitably fail.
The biggest culprits are the 30 or so tests that check the output of
get_stylesheet. I think the main reason there are so many tests focusing on that function is that it brings together the output of a bunch of protected functions such asget_layout_styles,get_block_classesandget_css_variables, among others, and it's being used essentially to test the output of those functions.What is your proposed solution?
How can this be improved?
I don't love the idea of tests comparing CSS strings, because the outcome of the test relies too much on implementation details (the exact shape of the CSS string, which the
get_stylesheetfunction is not even responsible for). A possible alternative would be to check for the presence of one or another property or classname inside the string, instead of trying to match the whole string.In general, unit tests are useful to check that the behaviour of a function remains unchanged after an edit or refactor. If we're testing an exact string of CSS, then all the changes we make to these functions will alter the output, because our styles are continually evolving. So what's the point of these unit tests? They're never catching any actual bugs. If we can abstract what we're checking for a bit - say we check that the function outputs a valid CSS string, but not its exact shape - maybe the tests become more useful while not being such a maintenance burden.
I'd love to hear about other potential approaches here!
Other things we can do to mitigate the impact of these tests on developer experience:
get_stylesheetindependently.Further improvements for
class WP_Theme_JSONitself:get_svg_filtersfunction that isn't being used anywhere in either core or gutenberg, should we deprecate it? A quick check in https://www.wpdirectory.net/ doesn't show any use either.