Php Unit Extended Laravel Package

Getting Started

Before you install anything, check compatibility. The last tagged release is 2023-04-02, which predates PHPUnit 10/11's attribute migration and TestCase signature changes. Read the require-dev block of the package's own composer.json to see which PHPUnit major it was built against, then compare with your project:

composer show -a yoanm/php-unit-extended   # shows versions + requirements
composer require --dev yoanm/php-unit-extended:^1.0 --with-all-dependencies

Pin it to an exact version ("yoanm/php-unit-extended": "1.0.x") — with zero dependents and a single maintainer, a silent constraint bump is not something you want to debug mid-sprint.

Where to look first. The README on GitHub is likely thin; the real documentation is the source tree:

find vendor/yoanm/php-unit-extended/src -name '*.php' | sort
grep -rn "^\(abstract \)\?\(class\|trait\|interface\)" vendor/yoanm/php-unit-extended/src

You are looking for two things: an abstract base TestCase (extend it) and traits (compose them). Confirm which one dominates before you commit to a pattern — swapping later touches every test class in the suite.

First use case. Migrate exactly one test class, not the whole suite. Either change extends TestCase to the package's abstract test case, or use a single trait in an existing class:

use Yoanm\PhpUnitExtended\...; // whatever the src listing reveals

final class FooTest extends AbstractTestCase
{
    // existing tests unchanged
}

Run vendor/bin/phpunit --filter FooTest and diff the output. If the base class overrides setUp()/tearDown(), verify your parent::setUp() calls are present — a missing parent call is the most common silent failure when adopting a third-party base test case.

Implementation Patterns

Prefer traits over the base class. Traits compose into test classes that already extend your own internal TestCase (which likely carries your app's container bootstrapping, database traits, etc.). Extending Yoanm\...\AbstractTestCase forces you to give up that hierarchy or re-implement it. Traits are the lower-risk integration point, and they also fail loudly on method-name collisions rather than silently shadowing.

Wrap, don't spread. If the package offers custom assertions, expose them through a thin local base class so the vendor name appears in exactly one file:

abstract class AppTestCase extends BaseTestCase
{
    use SomeVendorAssertionsTrait;

    // project-wide helpers, container wiring, etc.
}

When the package is eventually abandoned — and at 0 stars / 0 dependents you should assume it will be — you replace the internals of one file instead of editing 400 test classes.

Use it for data providers, not assertions. Custom assertion helpers tend to encode opinionated failure messages that are hard to reconcile with your team's convention. Data providers and mock/fluent-stub helpers are where small test libraries earn their keep, because they remove boilerplate without changing what a failure looks like.

Keep it in require-dev and prove it. Confirm composer install --no-dev --prefer-dist still produces a working production autoloader; a stray non-dev requirement or a files autoload entry is the classic way these packages leak into prod.

Evaluate before adopting broadly. Run a one-week trial on a single module. If fewer than ~5 call sites appear, don't depend on the package — copy the two or three traits you actually use into tests/Support/ (MIT license permits it, keep the header). A vendored copy of 200 lines beats a dependency with no maintenance signal.

Gotchas and Tips

• PHPUnit 10/11 breakage is the headline risk. Data providers must be static, setUp(): void is enforced, and docblock annotations (@dataProvider, @covers) are superseded by attributes. Any trait using annotations will emit deprecations on 10.x and fail on 11. Grep for @dataProvider and @covers in vendor/yoanm/php-unit-extended/src before upgrading PHPUnit.
• Trait method precedence. If a trait and your own base class define the same method, the class wins silently and the trait's version never runs. Use --debug plus a throwaway var_dump(__TRAIT__) or (new ReflectionMethod($this, 'methodName'))->getFileName() to confirm which implementation is actually executing.
• Static analysis will complain. Small packages rarely ship generics for assertSame/mock helpers, so PHPStan/Psalm at level 6+ will flag mixed types. Add a scoped ignore for vendor/yoanm/php-unit-extended/* in phpstan.neon rather than lowering your baseline.
• Debugging failing custom assertions. Set PHPUNIT_TESTSUITE_COMPILER style diagnostics aside and use --filter with --debug; when the failure message comes from a vendor trait, the stack trace points at the trait file — read it directly, it's the only documentation you have.
• Extension points. Override protected helpers in your local wrapper class rather than editing vendor/. If nothing is protected, the package wasn't designed for extension and you should copy instead of depend.
• Version drift. With one release in the last few years, composer update will never move you forward — that's safe, but also means PHP 8.4+ deprecations (implicit nullable params, dynamic properties) will surface in the package and you'll be patching a fork. Budget for that, or vendor it now.
• Licensing is clean (MIT) — no attribution burden beyond retaining the notice if you copy files, so extraction is a genuinely low-friction escape hatch.