Pest Plugin Realtime Laravel Package

Product Decisions This Supports

• Build-vs-buy on realtime test coverage. This is the decision the package most directly informs: do we spend engineering weeks building an in-house harness for realtime/broadcast assertions (channel auth, dropped connections, reconnection, presence), or do we adopt a small dev-only plugin and spend days on integration instead of weeks on construction? At 0 dependents and 1 star, adopting it is closer to "buy a head start" than "buy a platform" — we still own the CI harness either way.
• Test-infrastructure roadmap. Whether "realtime is covered by automated tests" becomes a committed quality goal this quarter or stays a manual/QA concern. Without a library in this space, realtime behavior typically goes untested or is asserted only through mocks that never exercise the socket path; this package is a candidate to make that goal affordable.
• Feature scoping for realtime surfaces. If realtime assertions are cheap, the product can justify richer realtime features (presence, typing indicators, live notifications, reconnect UX) because each ships with a testable contract. If they are expensive, the roadmap should favor poll-on-interval or server-rendered fallbacks that are trivially testable — a product decision, not just an engineering one.
• Reliability commitments and support tiers. Dropped-event and connection-recovery coverage is the evidence base for any customer-facing "live updates stay in sync" claim. This package directly supports deciding whether we can make that promise in SLAs, marketing, or enterprise contracts.
• Release-gate policy. Whether realtime test suites are allowed to block merges. That is a product-quality tradeoff (velocity vs. regression safety) that hinges on measured flake rate, which this package's evaluation produces.
• Platform standardization. Whether Pest is our standard runner and whether a shared realtime test recipe is codified centrally versus re-solved per team.

Important caveat for all of the above: the package's own materials describe two different products — one as a realtime test-feedback streamer for Pest, the other as a realtime browser behavior/broadcast tester. Both are plausible and useful, but they support different decisions. Product sign-off should require the maintainers or our spike to establish which one this is before we let it influence roadmap or quality commitments.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Laravel + Pest, with realtime features that matter to users (broadcasting, channels, presence/auth, reconnection).
• Realtime behavior is currently untested, mock-only, or covered by fragile bespoke scripts — i.e., there is real uncovered risk, not a theoretical gap.
• We can run the required broadcaster (Reverb/Pusher-compatible) in CI, or the package provides an in-process fake that meaningfully detects broken behavior.
• The plugin's assertion API is materially better than Laravel's built-in Event::fake() / Broadcast::fake() for the scenarios we care about — especially failures that mocks cannot catch, like dropped events and recovery.
• One engineer can be named owner, and we accept a pre-1.0 upgrade-review tax.
• We treat it as a reversible require-dev pilot, with pinning and a documented exit path.

Look elsewhere (or build in-house) when:

• We are PHPUnit-native, or the Pest/PHP/Laravel compatibility matrix does not match our pins.
• Realtime is not a product surface — the package has no value and should be dropped immediately.
• The package turns out to be a thin ergonomic wrapper over built-in fakes; then the honest answer is a short internal helper, not a dependency.
• Tests would require a live broadcaster per parallel CI worker with no documented, deterministic setup — the flakiness cost will likely exceed the coverage benefit.
• We need vendor SLAs, long-term support, or a stable 1.x API contract.
• Assertions can pass silently when the broadcaster is misconfigured (false greens) — that is worse than no coverage, because it converts an unknown risk into a false assurance.

Default posture: treat as an evaluation candidate, not a standard. Do not roll out team-wide before a measured flake rate exists.

How to Pitch It (Stakeholders)

To executives: This is a small, free, dev-only testing tool for one narrow problem — proving our live/realtime features actually work, including what happens when a connection drops. It never ships to customers and adds no production risk; removing it is one line in a config file. The reason to look at it is cost avoidance: realtime is where bugs are hardest to reproduce and where customers notice first. The reason to be cautious is maturity — pre-1.0, one star, no downstream users, and releases without meaningful notes, so we cannot judge upgrade risk from changelogs. Ask: approve a one-to-two-day, one-repo, non-blocking evaluation. Decision to scale comes back with a measured flake rate and CI cost, not an opinion.

To engineering leaders: Dev-only Pest plugin, auto-discovered, no build or deploy impact. The real cost is not the library — it is standing up a Reverb/Pusher-compatible service in CI with per-worker port isolation and clean teardown, and the flake risk of timing-sensitive assertions. Two findings to act on: (1) the project's own docs describe it inconsistently — as a realtime test-result streamer and as a realtime broadcast tester — so someone must confirm scope and read the v0.6.1→v0.6.2 diff before we commit; (2) we must prove a deliberately broken realtime path makes a test fail, otherwise we are buying false confidence. Pin exactly 0.6.2, spike 2–3 representative tests, run ~20 CI iterations, and keep new tests non-blocking until the flake profile is known.

To the team: If you already write Pest tests on a Laravel app with broadcasting, this is a cheap way to cover dropped events and reconnection — the scenarios where mocks lie. Expect a day of setup, mostly CI plumbing, then near-zero per-developer cost. It is an experiment with a named owner and an explicit exit plan, not a new standard.