Weave Code
Facade Laravel Package
testo/facade
Testo Facade is a static facade plugin for the Testo PHP testing suite that provides convenient static access to the suite's DI container through the global Testo class. It stores the container when the suite is configured, letting you resolve dependencies anywhere in your tests without passing the...
Static facade plugin for the Testo testing framework (split-published from php-testo/testo)
Frequently asked questions about Facade
- What is testo/facade and what does it do?
- It is a static facade plugin for the Testo PHP testing suite. It stores the suite's DI container when Testo is configured and exposes it through a global Testo class so tests can resolve dependencies without passing the container around. It is installed as a dev dependency.
- Is testo/facade a Laravel package?
- No. It is a plugin for Testo, a standalone PHP testing framework, and is not built as a Laravel package. It has no service provider, no Laravel version constraints, and no Laravel-specific integration. Its only role is exposing Testo's DI container through a global Testo class.
- Can I use testo/facade with Laravel instead of PHPUnit or Pest?
- Not as a replacement for Laravel's native testing tools. Laravel already provides container access through $this->app, app(), and Pest helpers, so testo/facade duplicates capability only if you adopt Testo itself. For Laravel applications staying on PHPUnit or Pest, it adds no value.
- How do I install testo/facade?
- Run composer require --dev testo/facade. There is no service provider to register and no config to publish. You still need a working Testo suite, and the plugin must observe suite configuration for the facade to become active.
- Do I need a service provider or config file for testo/facade?
- No. The package is a dev-only plugin with no Laravel service provider and no configuration file to publish. Integration is just the Composer require plus a Testo suite bootstrap that configures the container.
- How does the global Testo class get access to the DI container?
- The plugin stores the container when the suite is configured, then the global Testo class resolves from that stored container. This is a global mutable singleton with a thin static wrapper. It is convenient inside Testo, but it inherits the usual risks of global state in tests.
- Does testo/facade reset the container between tests?
- The README does not document an explicit reset API; the plugin only stores the container when the suite is configured. Because it is global static state, you should treat teardown as caller-managed until Testo documents otherwise. Container leakage between tests is a known hazard with this pattern.
- Does testo/facade support parallel test execution or forked workers?
- The README does not address parallel or forked execution. Static container binding is the pattern most likely to break under forked workers unless Testo scopes the container per process. Validate this in a pilot before relying on it.
- What happens if I call Testo before the suite is configured?
- The README does not specify the failure mode. With a thin static wrapper over global state, an unconfigured call may result in an opaque null dereference rather than a typed exception. Check Testo's suite bootstrap and add a guard in your own test setup.
- Is testo/facade actively maintained and where do I report issues?
- The repository is a read-only mirror synchronized from php-testo/testo on every release, so issues and pull requests belong in the main monorepo. The project is single-maintainer and pre-1.0 with no dependents, so sustainability is a real consideration. If Testo stalls, this plugin stalls with it.
Weaver
How can I help you explore Laravel packages today?