Getting Started

Read this first: mazarini/test-bundle is a Symfony bundle, not a Laravel package. The -bundle suffix, the mazarini namespace, and the "fake entities and services" pitch all point at Symfony's test-double conventions (bundle registration via config/bundles.php, services wired through DependencyInjection/). There is no Illuminate\Support\ServiceProvider, no extra.laravel.providers block, and no package discovery. If you are in a Laravel codebase, you are not "installing" this package so much as borrowing source files from it.

Because adoption is effectively zero (0 stars, 0 dependents) there is no README-driven happy path you can trust. Your first 15 minutes should be spent auditing, not integrating:

composer.json — check the require block. Look for symfony/framework-bundle, a php constraint, and any symfony/* version pins. If it requires framework-bundle, it will not install cleanly into a Laravel app without dragging Symfony's HTTP kernel in.
Last commit / last release tag — a package with no stars and no recent activity is a liability, not a dependency. Check whether it targets an EOL PHP or Symfony version.
src/ — find the actual fake entity classes and fake service implementations. This is the only part with real value; the bundle wiring is the part you will likely discard.
LICENSE — GPL-3.0. Do this before you write a single line of code against it (see Gotchas).

The realistic first use case is not "install the bundle." It is: you have a test suite drowning in hand-rolled Mockery::mock() chains and fixture arrays, and this package's fake entities give you concrete, predictable objects with sensible defaults. So the pragmatic first experiment is to copy two or three of the fake entity classes into tests/Support/Fakes/, strip the Symfony annotations/attributes, and see whether they actually save you keystrokes versus Laravel's own factories and fake().

Implementation Patterns

Pattern 1: Borrow the fakes, drop the bundle

For a Laravel app this is the only pattern that makes sense. Copy the plain-PHP fake entity classes out of src/ into your tests/ tree, remove any @ORM\ attributes or container annotations, and treat them as your own. You get the value (pre-shaped test doubles) without the Symfony container, without the GPL question attaching to a runtime dependency, and without a Composer entry you have to maintain.

Trade-off: you now own the code. That's fine for a handful of small classes; it's a maintenance smell if you find yourself copying dozens.

Pattern 2: Container substitution (Symfony context only)

If you actually are in a Symfony codebase, the intended workflow is: the bundle registers fake services under their real interface/alias, you enable the bundle in the test environment only, and your functional tests get deterministic collaborators for free instead of mocking everything. The integration tip that matters is environment scoping — never register fake services in config/bundles.php unconditionally, or you will eventually ship a fake to production and spend an afternoon debugging why an email never sent.

Pattern 3: Fake-instead-of-mock at the seam

Wherever you currently write $this->mock(SomeGateway::class, fn ($m) => $m->shouldReceive(...)), prefer a concrete fake object with overridable methods:

final class FakePaymentGateway implements PaymentGateway
{
    public array $charges = [];

    public function charge(int $cents): Receipt
    {
        $this->charges[] = $cents;
        return new Receipt('fake-' . count($this->charges));
    }
}

This is where a package like this earns its keep — assertions become assertCount(1, $fake->charges) rather than verifying mock expectations. Use the package's fakes as a template for this shape even if you don't use the classes themselves.

Pattern 4: Cross-check against what Laravel already gives you

Before adopting anything here, inventory your existing tools. Laravel's Http::fake(), Bus::fake(), Event::fake(), Queue::fake(), Notification::fake(), model factories with fake(), and Carbon::setTestNow() already cover the majority of "fake services" needs. A third-party fake-entity bundle is most defensible for domain objects that are awkward to build via factories — deeply nested aggregates, value objects with invariants, stateful services with call-history assertions.

Integration tips

Isolate to the test autoloader. If you vendor a copy of any class, put it under "autoload-dev" in composer.json so it can never leak into production code.
Bind fakes via the container in TestCase::setUp(), not in a service provider, so each test can swap in a different fake instance.
Don't fight the bundle's assumptions. If a class depends on a Symfony RequestStack or ContainerInterface, that's a signal to reimplement rather than adapt.

Gotchas and Tips

The license is the headline problem. GPL-3.0 is a strong copyleft license. Distributing a Laravel application that includes GPL-3.0 code generally obliges you to release that application under GPL-3.0 as well. For a commercial or SaaS product this needs a real legal review, not a guess. Note that if the code is only in autoload-dev and never distributed, the analysis is different from a require entry — another argument for the copy-into-tests approach, but confirm with counsel rather than with a README. Many PHP packages that intend permissive licensing accidentally ship GPL because of a template mistake; check whether the header actually matches the author's intent before assuming it's binding.

Zero-stars, zero-dependents is a risk signal, not a quality signal. There is no issue tracker activity to learn from, no Stack Overflow corpus, no security advisory feed watching it. You are the only person debugging this. Budget accordingly, and pin an exact commit hash if you do require it — a ^1.0 constraint on an unmaintained package is how you get a surprise major-version break or a yanked tag.

Symfony/Laravel container mismatches will bite. Symfony autowiring, service aliases, and bundle compiler passes have no equivalent in Laravel's container. If a fake service is defined in Resources/config/services.yaml with an alias, Laravel will not resolve it; you'd have to manually $this->app->bind() it. Expect to spend more time on wiring than on the fakes themselves.

PHP and Symfony version pins. Small bundles from individual authors frequently pin php: ^7.4|^8.0 and symfony/framework-bundle: ^5.4. On PHP 8.3+ or Symfony 7 that resolves to nothing or forces dependency downgrades across your whole project. Check with composer why-not mazarini/test-bundle before installing.

Debugging tips when fakes misbehave:

Dump the container (bin/console debug:container --tag=..., or in Laravel app()->getBindings()) to confirm which implementation actually resolved — a fake silently losing to a real binding is the most common failure.
If a fake returns static data, your test may be passing for the wrong reason. Assert on the fake's recorded calls, not just on the output.
Watch for fakes that hold mutable state across tests. Fakes are not mocks; if the instance is a shared container singleton, call history accumulates and your second test sees the first test's data. Bind as a non-shared service, or reset in tearDown().

Extension points are minimal by design. A test-helper bundle is not architecture; it's a bag of classes. The intended extension is subclassing or reimplementing the fakes. Don't look for configuration knobs, events, or compiler passes — and if you find yourself needing to patch one of the fakes, that's the moment to stop using the package and write your own twenty-line version.

Bottom line for a Laravel team: treat this as a source of inspiration and possibly a few copyable classes, not as a dependency. The overlap with Laravel's native faking and factory tooling is high, the maintenance risk is real, and the GPL-3.0 license is a gating question you should answer before the first composer require.

Test Bundle Laravel Package