Skip to content

29: Cover the branches a regression could take silently - #43

Open
nikolaystrikhar wants to merge 1 commit into
28-notices-test-controlsfrom
29-uncovered-branches
Open

29: Cover the branches a regression could take silently#43
nikolaystrikhar wants to merge 1 commit into
28-notices-test-controlsfrom
29-uncovered-branches

Conversation

@nikolaystrikhar

Copy link
Copy Markdown
Contributor

What: tests for Conflict\Detector's registration loop, Absorber::boot()'s retry-after-throw and provider seam, the Plugin\Loads_Plugin_Functions guard, and the activation record's network scope.

Usage:

$this->register( $clean_sub_plugin );      // no standalone
$this->register( $conflicted_sub_plugin ); // and this one is in conflict
$this->assertTrue( $detector->has_conflict() );

Why this way:

Every multi-entry detector test registered the conflicted sub-plugin first. So checking only the first registration passed the whole file, while a host bundling two plugins where the second standalone is active got nothing resolved and nothing explained.

boot() sets $booted last on purpose, so a host that fixes a broken bootstrap and calls again gets a working library rather than a silent no-op. Moving that line to the top of the method broke no test.

The load-guard trait's guard never ran. Both callers require_once core's plugin.php in setUp() so uopz can stub it, which makes function_exists( 'deactivate_plugins' ) true before the guard is reached. It is now driven against a throwaway WordPress root, asserting which name the guard asks about — the invariant is that it must not be the shimmable one.

The activation record is a network option, and nothing in the suite had ever called switch_to_blog().

Detector::has_conflict() never walked past a non-conflicting first entry --
every multi-entry case registered the conflicted sub-plugin first, so checking
only the first registration passed the file. A host bundling two plugins where
the second one's standalone is active got nothing resolved.

boot() sets $booted last so a boot that threw can be retried; moving that line
to the top broke no test. It binds its own Provider_Interface only when nothing
answers to one already; no test bound a double before booting.

Loads_Plugin_Functions guards on deactivate_plugins() and deliberately not on
is_plugin_active(), which is a common third-party shim -- but both callers
require the file in setUp so the guard never ran. Covered now against a
throwaway WordPress root, asserting which name the guard asks about first.

And the activation record's network scope, which no test reached: there was no
switch_to_blog() anywhere in the suite.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant