Tomato Dusk Laravel Package

Product Decisions This Supports

• Release confidence / regression coverage: tomato-dusk extends Laravel Dusk so the team can run browser-level tests against the TomatoPHP admin panel. That directly supports go/no-go decisions on releases: every admin-facing change (forms, tables, auth flows, settings screens) can be gated by an automated smoke suite instead of manual QA passes.
• Build vs. buy on test tooling: this is a thin, free adapter over an existing framework primitive (Dusk). The build alternative — hand-rolling Dusk setup, base test cases, and admin-panel selectors — is days of engineering plus ongoing maintenance. Buying/ adopting here is the cheaper path if you are already on TomatoPHP.
• Roadmap sequencing for QA investment: adopting this is a low-commitment first step toward E2E coverage. It's a reasonable "phase 1" before committing to a broader test pyramid investment (unit + feature + E2E), and it de-risks later decisions about CI capacity and test-flake budgets.
• CI/CD gating decisions: browser tests have real cost (headless Chrome in CI, runtime, flake). This package makes the authoring cheap but does not solve runtime cost. Use it to prototype the suite, then decide whether to gate merges or only run nightly.
• Vendor/ecosystem dependency tracking: the package is part of the TomatoPHP family, so adoption is a soft commitment to that ecosystem's release cadence, PHP/Laravel version support, and long-term maintenance — a roadmap input for platform standardization.
• Use cases it unblocks: admin-panel acceptance tests, post-upgrade verification of the Tomato admin UI, and reproducible bug reports (a failing Dusk test as the bug artifact).

On v1.1.1 specifically: this is a patch release whose notes are only a compare link between v1.1.0 and v1.1.1, with no described features, fixes, or breaking changes. Under semver that signals bug-fix/maintenance scope. It changes no product decision on its own — treat it as routine dependency hygiene, not a capability change. Before upgrading, read the commit diff directly; the changelog provides no signal for a PM to act on.

When to Consider This Package

Adopt when:

• You are running TomatoPHP's admin panel (Filament-based) and want browser tests that already understand its conventions, rather than writing selectors and scaffolding from scratch.
• Your team is PHP-first and you'd rather keep tests in the same language and repo as the application — no Node toolchain, no second CI pipeline.
• You need a small, fast acceptance suite covering critical admin journeys (login, CRUD, permissions), not exhaustive cross-browser coverage.
• You want a low-friction proof of concept for E2E testing before justifying a larger QA investment.
• You can run headless Chrome in CI and accept the associated runtime cost.

Look elsewhere when:

• You are not on TomatoPHP — the value proposition is largely the admin-panel integration, and a generic Dusk setup or Playwright/Cypress would be a better fit.
• You need multi-browser or mobile-web coverage — Dusk is Chromium-centric; Playwright is the stronger choice.
• Your team is JavaScript/TypeScript-native — maintaining PHP test infrastructure for a JS-heavy product adds cognitive overhead.
• Test flakiness at scale is a known pain point — Dusk suites are notoriously slow and flaky as they grow; a JS runner with better parallelism and tracing may be the more durable bet.
• Long-term maintenance risk matters — this is a small, single-vendor ecosystem package with terse release notes. If you need vendor SLAs or predictable support, factor that in; be prepared to fork or own the wrapper.
• PHP/Laravel version support is unverified for your stack — confirm compatibility before committing, since the changelog offers no guidance.

How to Pitch It (Stakeholders)

To executives: This is a free, small add-on that lets our QA and engineering teams automatically verify the admin panel before each release, instead of relying on manual click-throughs. It's low cost, low risk, and reversible — a test dependency, not a production dependency, so it cannot break the live product. The realistic benefit is fewer admin-panel regressions reaching customers and less staff time spent on repetitive manual checks. The newest release (v1.1.1) is a maintenance patch with no new features and no announced breaking changes, so there is nothing to decide here — it's routine upkeep. Recommendation: pilot it on one admin workflow, measure time saved and test reliability over a sprint, then decide whether to expand.

To engineering: This is a thin wrapper over Laravel Dusk tailored to the TomatoPHP admin panel — it should save us the boilerplate of base test cases and selectors, and keeps our test suite in PHP within the same repo and CI pipeline. Trade-offs to weigh: Dusk runs are slow and get flaky as suites grow, and we'll need headless Chrome wired into CI. The v1.1.1 changelog is just a compare link, so review the diff before bumping the lockfile — assume nothing about what changed. Keep the suite scoped to critical admin journeys (auth, CRUD, permissions) and don't let it become the primary regression net; pair it with feature tests. If we later need cross-browser or mobile coverage, plan to migrate to Playwright rather than fight Dusk.