Laratesto Laravel Package

Product Decisions This Supports

• Test-tooling standardization: whether to standardize Laravel service tests on Testo + laratesto instead of PHPUnit/Pest. The package's core value is letting Laravel test classes be discovered by Testo's class-level #[Test] attribute, so test declaration stays declarative and PHPUnit-free.
• Framework coexistence vs. consolidation: whether a repo may run two test paradigms during migration, and how long. v0.8.3 specifically improves fidelity of the Laravel bridge (LaravelTestCase / InteractsWithLaravel), which affects how safely a team can run Testo tests side-by-side with an existing suite.
• Runtime baseline planning: the package pins PHP >= 8.3. That is a real constraint on the platform roadmap and should be checked against the service estate before any pilot. PHP 8.6 remains blocked upstream (nette/schema), so 8.6 adoption is decoupled from this package — a scheduling input, not a blocker.
• Agent-assisted engineering investment: the release ships updated bundled Agent Skills and maintains English/Russian documentation. If the org is investing in agent-readable repo conventions and tooling, a test framework whose usage is documented for agents is a differentiated input to that decision — worth a timeboxed evaluation rather than a default.
• Build vs. buy: this is a thin integration layer over Testo. Building the equivalent in-house is low-differentiation work; the honest comparison is "adopt and pin" vs. "stay on PHPUnit", not "adopt vs. build".

When to Consider This Package

Consider it when:

• The service is greenfield or already on PHP 8.3–8.5, and the team is willing to standardize on Testo rather than mix frameworks indefinitely.
• You want attribute-driven, low-boilerplate test discovery and are willing to accept a pre-1.0 dependency.
• You want a verified Laravel integration: this release was validated against a fresh Laravel 13.11 skeleton installed from Packagist via ZIP distribution — no path repositories, no platform overrides, no PHPUnit — and the resolved consumer (Laravel 13.37.0, Testo 0.10.56) passes.
• You are running an internal pilot on agent-assisted development and want tooling whose conventions the agent can actually read.
• Localization matters: English and Russian guides are both kept current, with examples re-run on PHP 8.3.35, 8.4.26 and 8.5.11.

Look elsewhere when:

• You need ecosystem ubiquity: JUnit XML reporting, broad IDE integrations, established coverage pipelines, and a large hiring pool. PHPUnit/Pest remain the low-risk default here.
• You require vendor support, an SLA, or a multi-maintainer bus factor. At v0.8.x this reads as a small, concentrated-maintainer project — confirm maintainer depth before it touches a revenue-critical suite.
• You are on PHP < 8.3 or are committing to PHP 8.6 in the near term.
• You need API stability guarantees; pre-1.0 means pin exact versions and expect churn.

How to Pitch It (Stakeholders)

For executives (one paragraph): ichinya/laratesto is a small, free, open-source bridge that lets Laravel applications run their tests on Testo instead of PHPUnit. The v0.8.3 release is a corrective patch — it fixes discovery of class-level #[Test] attributes on Laravel test classes and tightens the bridge so inherited and user-overridden tests are handled correctly. No breaking changes, no dependency changes, no runtime requirement changes. The ask is not an org-wide mandate; it is a one-service, one-sprint pilot with a pinned version and PHPUnit as the documented fallback. Cost is engineering time only; the downside is bounded because the package is additive and removable.

For engineering leads: the release is narrow and well-evidenced for its size — 108 unit / 863 assertion and 120 Laravel / 429 assertion runs on PHP 8.3.35, CI green on 8.3, 8.4 and 8.5 plus real coverage, Rector clean, and a published-package install verified in a clean Laravel 13 skeleton without PHPUnit. The practical change: class-level attributes now work as documented for LaravelTestCase and InteractsWithLaravel users, with bridge helpers and trait aliases excluded while user overrides and inherited user tests are preserved. Treat the pre-1.0 version as a pin-and-track dependency and re-validate on each minor.

Decision requested: approve a timeboxed pilot on one non-critical service, with a written exit criterion (team velocity on tests, CI reliability, upgrade friction over two minor releases).