Phpunit Extensions Laravel Package

Getting Started

Reality check first. padraic/phpunit-extensions is archived (last release 2017-09-10), has 0 dependents on Packagist, and exists only as internal plumbing for the long-abandoned Humbug mutation-testing tool. There is essentially no day-to-day leverage in a new project — you would only touch this if you are maintaining a legacy Humbug pipeline or reviving an old test suite. Budget accordingly.

Minimum steps to evaluate it:

1. Confirm it can even install in your environment. The package predates PHPUnit 6's namespace move (PHPUnit_Framework_TestCase → PHPUnit\Framework\TestCase) and the PHPUnit 10 listener removal, so it will only resolve against the PHPUnit 4/5 line:

   composer require --dev padraic/phpunit-extensions
   # if resolution fails, pin explicitly:
   composer require --dev phpunit/phpunit:^5.7 padraic/phpunit-extensions:dev-master
   

   Do this in a throwaway Docker image (PHP 5.6–7.1) rather than in your main lockfile.

2. Look first at three places, in this order:

   • composer.json — the require block tells you exactly which PHPUnit version the extension was built against. This is the single most important fact about the package.
   • src/ — the API surface is tiny. Everything lives under the Humbug\PhpUnit\Extensions namespace (note: Humbug, not Padraic — the Composer vendor name and the PHP namespace do not match).
   • README.md — read it knowing it was written for Humboldt-era PHPUnit; treat every snippet as "verify against src/ before pasting."

3. First use case: wiring the bundled PHPUnit extension into a test run. Because the package is a PHPUnit listener/extension, the entry point is XML config, not application code:

   <!-- phpunit.xml.dist -->
   <phpunit bootstrap="vendor/autoload.php">
     <testsuites>
       <testsuite name="legacy">
         <directory>tests</directory>
       </testsuite>
     </testsuites>
     <listeners>
       <!-- FQCN taken from src/ – do not guess it -->
       <listener class="Humbug\PhpUnit\Extensions\…"/>
     </listeners>
   </phpunit>
   

   Run vendor/bin/phpunit --debug and confirm the listener fires before building anything on top of it. If it does not fire, the class name or the PHPUnit version is wrong — stop there.

Implementation Patterns

Treat it as a black-box dependency, not a library you code against. The healthy pattern is: Humbug or your legacy runner invokes PHPUnit, PHPUnit loads the listener, the listener records per-test outcomes. Your application tests should not use Humbug\PhpUnit\Extensions\… directly. Keeping that boundary makes the eventual removal a config change instead of a refactor.

Isolate the legacy run. Put the old PHPUnit + this extension in their own CI job, own Docker image, and own phpunit.legacy.xml. New tests run on modern PHPUnit; the legacy job runs the archived stack and reports status separately. Never let the old constraint leak into the root composer.json.

Subclass only if you must customise behaviour. If you need to change how results are collected, the usual pattern is to extend whatever TestCase or listener the package exposes, override the one hook you care about, and keep your override in tests/Support/. Forking the package is often cleaner than subclassing, given it will never receive upstream fixes.

Use it as a reference implementation when migrating. The most valuable pattern for a current codebase is to read how the extension hooks PHPUnit, then reimplement that in the modern API:

• PHPUnit ≤ 9: implement PHPUnit\Framework\TestListener and register it in <listeners>.
• PHPUnit ≥ 10: implement PHPUnit\Runner\Extension\Extension with bootstrap() / executeBeforeTest() and register it in <extensions>.
• Mutation testing itself: replace Humbug with infection/infection. It is actively maintained, integrates with modern PHPUnit, and does not need this package at all.

Pin everything, twice. Pin the PHPUnit version in composer.json and the extension to a commit hash ("padraic/phpunit-extensions": "dev-master#<sha>"). There will be no tagged fix if dev-master moves or the repo is deleted.

Gotchas and Tips

• Namespace/package mismatch. The Composer name says padraic/…; the code is Humbug\PhpUnit\Extensions\…. IDE auto-import and composer show will disagree. When debugging "class not found," check the PSR-4 mapping in the package's composer.json before anything else.
• It will not install on modern PHP. The PHPUnit 4/5 constraint transitively caps you at PHP ~7.1, and its dependencies use long-removed APIs. composer update on PHP 8.x will fail with an unhelpful conflict. Do not fight it — containerise it.
• PHPUnit API churn is the real risk. PHPUnit_Framework_TestCase and PHPUnit_Framework_TestListener were renamed in PHPUnit 6; TestListener was removed entirely in PHPUnit 10. Anything in this package that references the old PHPUnit_* symbols is dead on arrival for current suites.
• Listener output breaks strict modes. Older listeners sometimes echo progress. If you enable beStrictAboutOutputDuringTests="true" or run with --disallow-test-output, those echoes get reported as test failures. Run with --debug --verbose first to see whether output is coming from the listener or from tests.
• Config quirks. Listeners only load from the active phpunit.xml; if you pass --no-configuration or --bootstrap manually, nothing fires and you will wrongly conclude the package is broken. Verify with --debug that your config file was actually loaded.
• Debugging path: reproduce with a one-test suite, run vendor/bin/phpunit --debug --verbose, and add a var_dump/error_log inside the listener's startTest/endTest equivalent. Because there are no dependents and no recent issues, you are the only support channel.
• Extension points are effectively frozen. There are no maintainers to merge changes. If you need a behaviour change, fork, add a replace entry in your root composer.json if necessary, and vendor the fork under your org namespace. Document the fork's origin and the exact commit so a future maintainer can unwind it.
• Exit criteria. Write down now why this dependency exists and what replaces it. For most teams the answer is "delete it and use Infection"; having that sentence in the README saves the next person a day of archaeology.