Facade Laravel Package

Product Decisions This Supports

• Build vs. buy on test ergonomics: testo/facade solves a ~20-line problem (a global static holder for the suite's DI container). The real decision isn't "should we adopt this plugin" but "is the container-access convenience worth any dependency at all," given we could vendor an equivalent helper in an afternoon. Treat the package as a signal of what the Testo ecosystem considers table-stakes DevEx, not as a capability we couldn't otherwise obtain.
• Testing-stack roadmap: This package only has value if we standardize on Testo. Adopting it is effectively a small, reversible commitment to the framework's plugin model (install-time plugin registration, container lifecycle hooks). Use it as a cheap probe of whether Testo's plugin conventions fit our codebase before committing to the larger migration.
• Test-authoring conventions: The facade enables Testo::get(Service::class)-style access in tests. That's a policy decision as much as a technical one — do we want service-location in tests, or explicit fixture injection? Whichever we pick becomes a style-guide and code-review rule that outlives the package.
• Use cases it unlocks: integration/functional suites that need real services (DB connections, HTTP clients, config, clocks) without hand-rolling a container bootstrap per test file; shared base test cases that want access to app wiring; ad-hoc test utilities that currently take a container argument threaded through every call.
• Prioritization input, not a feature: Nothing user-facing ships because of this. It belongs in the "developer productivity / tech-debt budget" bucket, sized in hours, not sprints.

When to Consider This Package

Adopt (or, more honestly, trial) when all of the following hold:

• We are already running Testo, or are in an active evaluation spike of it — this plugin has zero standalone value.
• We have a meaningful number of tests that need container-resolved services, so the boilerplate savings are measurable rather than theoretical.
• We can tolerate pre-1.0 churn and a single-maintainer bus factor without it blocking a release.
• Our test suite does not rely on strict per-test isolation guarantees that global static state would undermine (or we've verified the container is reset between tests).

Look elsewhere — or write the ten-line helper ourselves — when:

• We're on PHPUnit, Pest, or any non-Testo runner. That's the overwhelming majority case, and this package is simply inapplicable.
• Static/global state is banned by team convention or breaks parallel test execution and container reset semantics.
• We need support SLAs, security review, or vendor accountability. A read-only mirror with 0 stars, 0 dependents, and issues routed to a different repo is the opposite of a supportable dependency.
• The container access is needed in only a handful of tests; a local trait or explicit injection is cheaper than adding a package and a convention.
• We're already uneasy about Testo itself — adopting its plugins deepens the coupling and makes a later exit more expensive than it looks.

Note the metadata honestly in any adoption record: read-only mirror, auto-synced from php-testo/testo, maturity limited to README + CHANGELOG, no dependents. That's "experimental," not "approved dependency."

How to Pitch It (Stakeholders)

To executives: This is a small developer-productivity plugin for a testing framework we're evaluating. Cost is negligible and the code is trivial to replace, so the financial exposure is effectively zero. The real risk is strategic, not financial: it only pays off if we commit to Testo, and Testo is a young, single-maintainer project with no ecosystem traction (0 stars, 0 dependents on this package). Recommendation: treat it as a spike, not a standard. Approve a timeboxed evaluation, not an adoption.

To engineering: testo/facade gives tests a global Testo class that exposes the suite's DI container, removing per-test container plumbing in integration-style tests. Two caveats to design around before we rely on it: (1) it's a read-only mirror of plugin/facade/ in the main monorepo — file issues and PRs upstream, and expect versions to move with the monorepo, not independently; (2) it's global static state, so confirm the container is reset between tests and that parallel runs stay isolated. If either caveat is unacceptable, a small internal trait gives us the same ergonomics with no third-party surface.