Improve page cache detection test

[dhaval-parekh]

Summary

Fixes #6830

This PR improves the mechanism to detect page caching availability on websites.

Checklist

• My code is tested and passes existing tests.
• My code follows the Engineering Guidelines (updates are often made to the guidelines, check it out periodically).

[github-actions]

Plugin builds for 1d25cc4 are ready 🛎️!

• Download development build
• Download production build

[codecov]

Codecov Report

Merging #6849 (844cd16) into develop (b311b57) will increase coverage by 0.06%.
The diff coverage is 97.27%.

❗ Current head 844cd16 differs from pull request most recent head 0d97691. Consider uploading reports for the commit 0d97691 to get more accurate results

@@              Coverage Diff              @@
##             develop    #6849      +/-   ##
=============================================
+ Coverage      78.46%   78.52%   +0.06%     
- Complexity      6735     6764      +29     
=============================================
  Files            202      202              
  Lines          20321    20395      +74     
=============================================
+ Hits           15944    16015      +71     
- Misses          4377     4380       +3     

Flag	Coverage Δ
php	78.52% <97.27%> (+0.06%)	⬆️
unit	78.52% <97.27%> (+0.06%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/Admin/SiteHealth.php	84.56% <97.16%> (+1.94%)	⬆️
src/Admin/OptionsMenu.php	94.73% <100.00%> (+0.03%)	⬆️

Much improved! Thank you.

[westonruter]

E2E tests seem to be stalling. I don't think they're related to this PR. cc @delawski

[westonruter]

Here are the scenarios I'm testing:

Failure to Do Loopback Request

With this plugin active:

add_action('template_redirect', function () {
	status_header( 500 );
	exit;
});

No Page Caching with Slow Response Time

With this plugin active:

add_action( 'wp_footer', function () {
	sleep(1);
} );

No Page Caching with Good Response Time

No special plugins active.

Page Caching Header(s) with Bad Response Time

Test plugin:

add_filter(
	'wp_headers',
	function ( $headers ) {
		$headers['etag'] = '"foo"';
		$headers['last-modified'] = gmdate('r');
		return $headers;
	}
);

add_action( 'wp_footer', function () {
	sleep(1);
} );

Note that since page caching response headers are present, the lack of a page caching plugin is not mentioned (since it's likely an external page cache is being used):

Page Caching Header with Good Response Time

Plugin:

add_filter(
	'wp_headers',
	function ( $headers ) {
		$headers['etag'] = '"foo"';
		$headers['last-modified'] = gmdate('r');
		return $headers;
	}
);

Note that since page caching response headers are present, the lack of a page caching plugin is not mentioned (since it's likely an external page cache is being used):

Page Caching Plugin with Good Response Time

With WP Super Cache active and with the following plugin active:

add_action( 'wp_footer', function () {
	sleep(1);
} );

Note that since the median time is used, the 1-second response time is disregarded:

[westonruter]

This is a huge improvement. Way more robust.

The only thing outstanding are the failing E2E tests.

[westonruter]

Note: I don't believe this scenario is ever possibly reached.

[delawski]

I've looked into the E2E tests issue and wasn't able to find the reason for it. Since I wasn't able to reproduce the issue locally, I had to play a guessing game on this.

First, I tried changing the selector that fails in multiple unit tests (90d9a16). It didn't help.

Then, I thought that maybe AMP plugin is not activated on the test environment for whatever reason (maybe new WordPress 5.9 or the recent update of Gutenberg npm packages?). I've added a rule to try activating the plugin from within E2E tests (4a4c490). It didn't help as well.

Lastly, I've rebased the branch onto develop to see if by any luck it helps but it didn't.

One more thing I did was to issue a new PR for another feature I just completed working on #6859. I branched off of develop yesterday so it's very fresh. The E2E tests are passing on that other branch so I'm totally disoriented right now.

I don't have more time to investigate the issue further today.

[westonruter]

I'm gonna push up some commits to debug this. I'll be doing some force-pushes to beware.

[westonruter]

It turns out the E2E tests were working perfectly! They were catching an actual problem which I've fixed in 188e0cd. The issue is it wasn't accounting for \AmpProject\AmpWP\Admin\SiteHealth::get_page_cache_detail() returning a WP_Error (as when loopback requests fail), and this resulted in the Settings page failing to load. So I've added the check to ensure it's an array value and that fixed the tests.

@delawski Thank you for wrestling with this in any case!