Code coverage cannot be generated due to weird global CSS output

[dingo-d]

Describe your bug

When using wp-pest to write integration tests, when checking the code coverage I get the following output:

<style id='esCssVariables-global'>:root {--global-custom-blocks-name: eightshift-block;--global-main-content-width: 12;--global-max-cols: 12;--global-base-font: Inter var;--global-code-font: JetBrainsMono;--global-z-index-header: 100;--global-z-index-drawer: 99;--global-z-index-overlay: 98;--global-breakpoints-mobile: 480;--global-breakpoints-tablet: 960;--global-breakpoints-desktop: 1440;--global-breakpoints-large: 1920;--global-grid-gutter: 2vw;--global-grid-side-padding: 8.33vw;--global-section-spacing-min: -300;--global-section-spacing-max: 300;--global-section-spacing-step: 10;--global-section-in-spacing-min: 0;--global-section-in-spacing-max: 300;--global-section-in-spacing-step: 10;--global-colors-black: #0C1B2C;--global-colors-black-values: 12 27 44;--global-colors-grey-blue-darker: #5E6C82;--global-colors-grey-blue-darker-values: 94 108 130;--global-colors-grey-blue-mid: #8A98AD;--global-colors-grey-blue-mid-values: 138 152 173;--global-colors-white: #FFFFFF;--global-colors-white-values: 255 255 255;--global-colors-white-opacity-50: #ffffff80;--global-colors-white-opacity-50-values: 0 0 0;--global-colors-orange: #FC6423;--global-colors-orange-values: 252 100 35;--global-colors-orange-dark: #D1521C;--global-colors-orange-dark-values: 209 82 28;--global-colors-grey-light: #D9D8D7;--global-colors-grey-light-values: 217 216 215;--global-colors-blue-super-light: #F8F9FD;--global-colors-blue-super-light-values: 248 249 253;--global-colors-blue-light: #EEF2FC;--global-colors-blue-light-values: 238 242 252;--global-colors-blue-dark: #222E42;--global-colors-blue-dark-values: 34 46 66;--global-colors-blue-mid: #C6D1F2;--global-colors-blue-mid-values: 198 209 242;--global-colors-blue-strong: #0142A6;--global-colors-blue-strong-values: 1 66 166;--global-colors-orange-opacity-50: #fc642380;--global-colors-orange-opacity-50-values: 0 0 0;--global-colors-black-opacity-25: #0e032540;--global-colors-black-opacity-25-values: 0 0 0;--global-colors-black-opacity-70: #000000b3;--global-colors-black-opacity-70-values: 0 0 0;--global-colors-black-opacity-6: #0000000f;--global-colors-black-opacity-6-values: 0 0 0;--global-colors-blue-super-strong-opacity-60: #08133199;--global-colors-blue-super-strong-opacity-60-values: 0 0 0;--global-colors-blue-super-strong-opacity-70: #081331b3;--global-colors-blue-super-strong-opacity-70-values: 0 0 0;}</style>Undefined variable: attributes

And no coverage gets generated

Steps to Reproduce

1. Setup a project
2. Install wp-pest
3. Setup integration tests as per instructions
4. Run coverage using: XDEBUG_MODE=coverage ./vendor/bin/pest --group=integration --coverage
5. See the tests passing, but coverage not being generated

Expected behavior

I should get code coverage as in regular Pest tests.

Screenshots, screen recording, code snippet

No response

Environment info

• PHP 7.4.30
• WSL (same happened on mac with Valet)

Please confirm that you have searched existing issues in this repo.

Yes

Please confirm that you have searched in our documentation and couldn't find the answer.

Yes

Please confirm that your bug occurs with all plugins uninstalled and with the default WordPress theme active.

Yes

[dingo-d]

My hunch is that the way $attributes just 'happen' in the view files is what trips up the code coverage.

Code coverage is basically walking through files and checking if the lines have been executed during the test run (a lot more complex than that but in essence 😅), and when it comes to the view files, and sees the $attributes variable out of nowhere it trips up and throws the undefined variable notice.

Still not sure where the CSS output comes out tbh.

The interim solution is to add

	<coverage processUncoveredFiles="true">
		<include>
			<directory suffix=".php">./src</directory>
		</include>
		<exclude>
			<directory>./src/Blocks/components</directory>
			<directory>./src/Blocks/custom</directory>
			<directory>./src/Blocks/wrapper</directory>
		</exclude>
		<report>
			<clover outputFile="tests/coverage/clover.xml"/>
			<html outputDirectory="tests/coverage/html" lowUpperBound="50" highLowerBound="90"/>
		</report>
	</coverage>

in the phpunit.xml file. This will skip over those parts that are throwing these notices and preventing the code coverage to be executed properly.

The real fix is... Not simple.

I recon the fix could be to add a proper 'loader' for view files where the $attributes, $manifest etc. can be passed as arguments, and then the view PHP file could reference them using $this->arguments. Similar to this approach:

https://github.com/dingo-d/woo-solo-api/blob/f4d186452e227b6c8a04c4d36fa098d0d100fcf7/src/View/BaseView.php#L74-L106

But this would require a careful rewrite of component and block loading in the eightshift-libs, plus all the blocks should be updated (to replace the 'magic' global variables appearing out of nowhere).

The positive could be that we might be able to cache some things (global manifest, etc.) and could have some performance gains.