- How do I install pest-plugin-realtime in a Laravel project?
- Install it as a dev dependency with composer require --dev kirschbaum-development/pest-plugin-realtime. Because it is a Pest plugin, it registers itself through Composer and Pest plugin discovery, so no manual service provider wiring is typically needed. It lives in require-dev only and contributes nothing to your production artifact, deploy pipeline, or runtime performance.
- Does pest-plugin-realtime need a running Reverb, Pusher, or Soketi server to test broadcasts?
- This is the single most important question to answer before adopting the package, and the v0.6.2 release does not document a CI setup or broker requirements. You need to verify whether the plugin ships an in-process fake or shim, or whether tests must reach a live broadcaster from the test runner. That answer drives most of the operational cost of using it.
- Which Pest, PHP, and Laravel versions does pest-plugin-realtime support?
- The exact compatibility matrix is not stated in the v0.6.2 release, so check the composer.json constraints and any CI matrix in the repository against your pinned Pest, PHP, and Laravel versions. Confirm the supported Pest major in particular, since the plugin only makes sense if Pest, not PHPUnit-native, is your test runner. Validate this before any spike work begins.
- How is pest-plugin-realtime different from Laravel's Event::fake() and Broadcast::fake()?
- The package positions itself around realtime testing helpers for live events, broadcasting, and connection recovery, but whether it goes beyond Laravel's built-in fakes is not documented in the release notes. If it turns out to be a thin ergonomic wrapper over Event::fake() and Broadcast::fake(), the value case weakens considerably. Review the source and existing tests to see what assertions it actually adds.
- Can pest-plugin-realtime be used in production code?
- No. It is a dev-only Pest plugin intended for your test suite, not for application runtime. It should sit in require-dev and never be loaded by the production artifact, so it cannot affect deploy pipelines or runtime performance. Removing one dev dependency plus the tests that use it fully reverses the decision.
- Is pest-plugin-realtime stable enough for CI given it is pre-1.0?
- At v0.x there is no semver stability guarantee: patch releases should generally be safe, but minor releases may include breaking changes. Every upgrade requires at least a quick review, which is a small but recurring tax. The bigger stability risk in CI is test flakiness from timing-sensitive realtime assertions, not the plugin's API.
- Why do realtime broadcast tests become flaky in CI?
- Realtime assertions are inherently timing-sensitive, so the dominant risk is flakiness injected into your CI rather than incorrect plugin behavior. Flaky tests erode trust in the whole suite, which is worse than a missing assertion. Before rolling out broadly, port two or three representative realtime tests and run them roughly 20 consecutive CI iterations to record an actual flake rate.
- What changed between pest-plugin-realtime v0.6.1 and v0.6.2?
- The only published artifact for v0.6.2 is an auto-generated GitHub compare link, with no curated release notes, no described features, and no migration guidance. Most likely it is a dependency bump or CI fix, but regression risk cannot be assessed from the notes alone. Someone must read the v0.6.1...v0.6.2 diff directly and confirm nothing changed in the plugin's public test API.
- Are there alternatives to pest-plugin-realtime for testing Laravel broadcasting?
- Laravel's own Event::fake() and Broadcast::fake() assertions cover many broadcasting cases without any extra dependency. Manual mocks and plain Pest assertions over your broadcast events are the other common approach. If the plugin largely duplicates those built-ins, staying with framework-native fakes is the lower-risk choice.
- Is pest-plugin-realtime actively maintained?
- Kirschbaum Development is a credible Laravel consultancy, but this is a small, narrowly scoped open source plugin, so bus factor and long-term maintenance are unproven. Check commit cadence, the open-issue backlog, and time-to-response over the last 6 to 12 months. Also confirm the license terms and whether its assertions can silently pass when the broadcaster is misconfigured, which would create false-green tests.