You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The PHPUnit scaffolding already exists and runs in CI, but exercises nothing:
Configs phpunit.{9,11,12}.xml.dist, composer scripts (test-php/phpunit via phpunit-select-config), yoast/phpunit-polyfills, and tests/php/bootstrap.php are all present.
.github/workflows/php-tests.yml runs composer test-php on every PR/push across PHP 8.2–8.5.
Gap 1:tests/php/bootstrap.php only loads the Composer autoloader. There is no WordPress runtime, and the core logic lives in procedural files (wp-cache-phase1.php, wp-cache-phase2.php) that are not autoloaded (the classmap covers src/ only). So functions like supercache_filename() are unreachable from a test.
Gap 2: Zero *Test.php files exist, so the CI step passes trivially and gives false assurance.
Goal
Make the procedural caching functions testable and land a first batch of tests, so the existing green CI step actually means something.
Decision required (why this is human, not agent)
Pick a testing strategy — this is an architectural call with trade-offs:
WordPress integration test library (wp-env / wordpress-tests-lib) — real WP + DB. Highest fidelity, slowest, needs DB service in CI.
Function mocking (Brain Monkey / Mockery) — mock apply_filters, get_blog_option, etc. Fast, no DB, but mocks can drift from real WP behaviour.
Lightweight stubs in bootstrap — define the handful of WP functions the targeted code calls. Minimal deps; only viable while the surface stays small.
Whichever is chosen, the bootstrap must also require the procedural files (or the relevant ones) so their functions are defined.
First test targets (pure / global-light)
supercache_filename() — assert the output is always a single, separator-free path segment given hostile filter input (regression guard for the filename-sanitization fix in Restrict supercache filename to a safe character set #1050).
Context
The PHPUnit scaffolding already exists and runs in CI, but exercises nothing:
phpunit.{9,11,12}.xml.dist, composer scripts (test-php/phpunitviaphpunit-select-config),yoast/phpunit-polyfills, andtests/php/bootstrap.phpare all present..github/workflows/php-tests.ymlrunscomposer test-phpon every PR/push across PHP 8.2–8.5.tests/php/bootstrap.phponly loads the Composer autoloader. There is no WordPress runtime, and the core logic lives in procedural files (wp-cache-phase1.php,wp-cache-phase2.php) that are not autoloaded (the classmap coverssrc/only). So functions likesupercache_filename()are unreachable from a test.*Test.phpfiles exist, so the CI step passes trivially and gives false assurance.Goal
Make the procedural caching functions testable and land a first batch of tests, so the existing green CI step actually means something.
Decision required (why this is human, not agent)
Pick a testing strategy — this is an architectural call with trade-offs:
wordpress-tests-lib) — real WP + DB. Highest fidelity, slowest, needs DB service in CI.apply_filters,get_blog_option, etc. Fast, no DB, but mocks can drift from real WP behaviour.Whichever is chosen, the bootstrap must also
requirethe procedural files (or the relevant ones) so their functions are defined.First test targets (pure / global-light)
supercache_filename()— assert the output is always a single, separator-free path segment given hostile filter input (regression guard for the filename-sanitization fix in Restrict supercache filename to a safe character set #1050).wpsc_get_realpath()/wpsc_is_in_cache_directory()— path containment logic.get_wp_cache_key()— key composition.Acceptance
composer test-phpruns at least one real test green across the CI PHP matrix.tests/phpnote) so future tests have a template to copy.