Laravel Mojito Laravel Package

Technical Evaluation

Architecture fit. Mojito is a require-dev-only testing utility, not a runtime dependency. It hooks into Laravel's view factory through a trait and a small service provider to let tests assert that a view was rendered and what data it received — without actually compiling the Blade template. This is architecturally clean: it has no production surface area, no database, no queue, no config publishing, and no service container bindings that affect the app. For a Laravel shop already on PHPUnit + Mockery, it fits the existing test architecture rather than introducing a parallel one. Fit is good but narrow: it only pays off in codebases with many controller/HTTP tests that assert on view output.

Integration feasibility. Very high. Installation is a single composer require --dev nunomaduro/laravel-mojito, then use Mojito in a test case. The API is small and ergonomic (assertViewWasRendered(), assertViewWasRenderedWith(), assertViewWasNotRendered(), and now an empty-view assertion added in v0.2.8), which lowers the cost of a spike to hours, not days. The main friction remains version alignment: the package targets the Laravel 5.8–8 / PHPUnit 8–9 era.

Release review (v0.2.8). The new release adds a single assertion (empty) via one community PR. Assessment impact: additive and low-risk, but not a change in posture.

• No breaking changes. Purely additive API surface; existing suite behavior is unaffected. No deprecations, no dependency-matrix changes declared.
• Marginal capability gain. A dedicated empty/falsy-data assertion is a minor ergonomic win — it lets a test express "view rendered with no meaningful data" without chaining assertViewHas closures. It does not unlock new use cases.
• Weak maintenance signal. This is the first release since 2021-04-08, and it is a single small PR merge. One minor commit does not establish a release cadence, PHPUnit 10/11 support, or Laravel 9/10/11 declarations. Treat the "unmaintained upstream" risk as unchanged in substance, with the release date updated.

Risk. Contained but real. Key risks:

• Effectively unmaintained upstream. v0.2.8 is the only recent activity after a ~4-year gap and contains one small addition; still no declared support for Laravel 9/10/11 or PHPUnit 10/11. On a modern stack it may still fail to install or behave unpredictably.
• Zero dependents. Effectively no community validation, no downstream bug reports, no ecosystem pressure to keep it current. The star count reflects historical interest, not current maintenance.
• Silent assertion drift. Test utilities fail worst when they pass vacuously — if Mojito's Mockery expectations stop binding to the view factory correctly after a framework upgrade, tests can go green while asserting nothing. The new empty assertion is subject to the same class of risk. This is the highest-severity concern because it degrades test-suite trust.
• Blast radius is bounded. Failure modes surface in CI, not production. That lowers the risk profile versus a runtime package.

Key questions.

1. What Laravel, PHP, and PHPUnit versions are we on today, and what is the near-term upgrade path? If Laravel ≥9 or PHPUnit ≥10, is a fork?
2. Does Laravel's native assertViewIs / assertViewHas / View::shouldReceive(...) already cover 80%+ of the value? If so, why add a dependency?
3. Does the new empty assertion materially change how many of our tests would adopt Mojito, or is it convenience on top of an adoption decision we'd make for other reasons?
4. Who owns this if upstream goes dark again — do we have a maintainer willing to vendor or fork a small codebase?
5. Do we have negative tests that prove assertions actually fail when views aren't rendered (guarding against vacuous passes)?

Integration Approach

Stack fit. Best fit is a Laravel monolith or modular Laravel app using Blade, PHPUnit, and Mockery, where HTTP/feature tests currently assert rendered HTML strings. Mojito lets those tests assert on view contracts (which view, which data) instead of brittle markup, decoupling tests from template churn. It is a poor fit for API-only services, Inertia/Livewire-heavy frontends, or teams standardized on Pest-only with no PHPUnit test base.

Migration path. Adoption is incremental and reversible by design. Add the trait to a shared TestCase or to individual test classes; do not modify application code. Decommissioning is equally cheap: remove the trait and replace assertions with native Laravel equivalents (assertViewIs, assertViewHas, View::shouldReceive). There is no data migration, no config, no runtime coupling — the exit cost is near zero, which remains the strongest argument for trialing it.

Compatibility. The gating constraint is the dependency matrix, and v0.2.8 does not change it:

• Greenfield/modern stack (Laravel 10+, PHPUnit 10+): treat as unsupported out of the box; requires a fork or skip.
• Legacy or pinned stack (Laravel 8-, PHPUnit 9-): low-friction, likely works as documented; v0.2.8 is a safe drop-in upgrade from prior 0.2.x.
• Mixed estate: scope adoption per-service rather than org-wide.

Sequencing.

1. Spike (1–2 days): install at v0.2.8 in one service, convert 3–5 representative view tests, including one using the new empty assertion, and measure readability and runtime delta.
2. Guardrail: write explicit negative tests proving assertions fail when a view is not rendered, closing the vacuous-pass risk.
3. Decision gate: compare against native assertions on the same tests; adopt only if the DX or speed win is demonstrable.
4. Pilot: roll out to one team/test suite, document conventions.
5. Scale or stop: expand only where it clearly reduces test maintenance; otherwise standardize on native assertions and avoid the dependency.

Operational Impact

Maintenance. The package remains effectively frozen. v0.2.8 is a single small PR merged after a long dormancy — welcome, but not a maintenance commitment. Treat it as vendored software we may need to own: budget periodic compatibility reviews at each Laravel/PHPUnit upgrade and name a maintainer who can patch or fork. The codebase is small enough that forking is realistic (days, not months), but that cost must be acknowledged up front rather than discovered during an upgrade crunch.

Support. Community-only, no vendor SLA, no active issue triage. Internal support model should be "one named owner + documented fallback to native assertions." Do not let it become load-bearing in a way that blocks upgrades.

Scaling. No production scaling implications — it never runs in production. Test-suite scaling is favorable: isolated view tests avoid Blade compilation and markup coupling, so suites get faster and less brittle as controller tests grow. The scaling limit is organizational: the more tests depend on it, the higher the cost of the eventual fork or migration.

Failure modes.

• Upgrade breakage: composer resolution failure or runtime errors on Laravel/PHPUnit upgrades — noisy, caught in CI, low severity.
• Vacuous assertions (highest severity): expectations silently detached from the view factory, producing green tests with no coverage. Applies equally to the new empty assertion. Mitigate with negative tests and periodic mutation-style spot checks.
• Partial-version drift: teams on mixed Mojito versions (pre- and post-0.2.8) see inconsistent available assertions in shared test helpers; pin the version.
• Mockery version conflicts: duplicated or conflicting expectations in complex test bases; surfaces as flaky or confusing failures.
• Abandonment drift: gradual divergence from framework testing idioms, making future migration more expensive than it looks today.

Ramp-up. Very low. One trait, a handful of assertion methods, and a mental model developers already have from Mockery. A competent Laravel engineer is productive in under an hour; team-wide documentation is a short README section. The onboarding cost is not the API — it is teaching the team when to use view isolation versus native assertions, and that discipline needs a written convention.

TPM recommendation. v0.2.8 is a safe, additive update and worth taking if we are already on the package, but it does not change the adoption calculus: it is one small assertion, not evidence of a maintained dependency, and it leaves the Laravel 9+/PHPUnit 10+ gap and the zero-dependents signal untouched. Worth a bounded spike in a legacy/pinned service with view-heavy tests; not worth adopting on a modern Laravel/PHPUnit stack without a fork commitment. Continue to treat Mojito as a tactical convenience with a named owner and a documented exit to native Laravel assertions, not as a strategic test-infrastructure investment.