Weave Code
Test Authenticaton Provider Bundle Laravel Package
smartassert/test-authenticaton-provider-bundle
A Symfony bundle from SmartAssert that provides a test authentication provider, letting functional and integration tests sign in users through configurable test credentials without a real identity backend.
Bundle providing users, frontend tokens and api tokens for test integrations
Frequently asked questions about Test Authenticaton Provider Bundle
- Is smartassert/test-authenticaton-provider-bundle a Laravel package?
- No. It is a Symfony bundle that registers at the kernel level and provides test users, frontend tokens and API tokens for test integrations. It ships no Laravel service provider, facade, publishable config or Artisan commands, so Laravel's container will not discover or boot it automatically. Laravel consumes Symfony components, not Symfony bundles, so there is no runtime fit for a Laravel application.
- Can I install this bundle in a Laravel application?
- You can add it as a require-dev dependency in principle because it is Composer-installable, but expect conflicts. The bundle pulls Symfony HTTP kernel and framework-bundle transitives that collide with the symfony/* versions Laravel already pins, so composer why-not will likely report clashes on symfony/http-kernel and symfony/event-dispatcher. There is no Laravel bridge, so any real use needs a custom adapter or a separate Symfony test kernel.
- Does it integrate with Laravel's Auth::fake(), Sanctum or Passport?
- No. The package exposes a Symfony test authentication provider only, with no guards, user providers or macros written for Laravel's auth stack. For Laravel tests, native tools such as actingAs, Auth::fake(), Sanctum::actingAs or a custom UserProvider fake cover the same ground. Using the bundle alongside Laravel auth would require glue code that duplicates what the framework already gives you.
- How do I install smartassert/test-authenticaton-provider-bundle?
- Install it with composer require --dev smartassert/test-authenticaton-provider-bundle and pin an exact version rather than a floating constraint. Note the package name contains a misspelling (authenticaton), so confirm the Composer namespace and the Packagist entry match the upstream GitHub repository before installing. Run composer why-not and composer audit in CI as part of the spike.
- Which PHP and Symfony versions does this bundle support?
- The provided evaluation does not list explicit PHP or Symfony constraints, so check the composer.json in the upstream repository for the require block. Resolve the Symfony major and PHP constraint against your existing lockfile before writing any test code, because dependency resolution tends to be where this spike stalls. Also verify any PSR-7 and PSR-18 interface requirements.
- Does this bundle need a live SmartAssert service or network access during tests?
- This is one of the open questions flagged in the evaluation and is not answered by the overview. The bundle is described as a test authentication provider that avoids a real identity backend, which suggests it is self-contained, but confirm whether a remote authenticator is required. If it makes network calls, that is a serious problem for deterministic CI test runs.
- Is smartassert/test-authenticaton-provider-bundle safe to use in production?
- No, treat it as test-only. It is a test authentication provider whose whole purpose is to fake sign-ins for functional and integration tests, so it must stay in require-dev and out of the production autoload graph. Keeping it out of production also limits the blast radius if the package is abandoned or retagged.
- Is the package actively maintained and popular?
- Community validation is effectively absent: zero stars, zero dependents and a single apparent maintainer, so there is no downstream canary. The most recent release date of 2025-12-01 is a positive signal, but release cadence and semver discipline are unverified. The MIT licence permits forking, so budget a quarterly review of upstream activity and document a fork trigger, such as six months without a release.
- Is this bundle a good fit for a Symfony test harness or polyglot monorepo?
- Yes, that is the only credible fit. The bundle is meaningful when the system under test is Symfony, or inside a standalone PHP test-support module or a polyglot monorepo where a Symfony test kernel is actually booted. For a Laravel-only codebase, the same capability is better met natively and the bundle adds dependency risk without benefit.
- What should I do instead for Laravel test authentication?
- Implement a Laravel-native fake: a custom UserProvider or guard fake, or the built-in actingAs, Auth::fake() and Sanctum::actingAs helpers, mirroring the provider contract your app already uses. The evaluation estimates roughly 100 lines of glue closes the same gap. Sequence it as a short spike first, record the decision, and only adopt the Symfony bundle if the native approach genuinely falls short.
Weaver
How can I help you explore Laravel packages today?