- How do I install volt-test/laravel-performance-testing in a Laravel app?
- Install it as a dev dependency with composer require --dev volt-test/laravel-performance-testing, then publish any config the package ships and define your first scenario. Because it targets the test and CI lifecycle rather than the request path, it belongs in require-dev rather than require. Check the README for the exact publish or configuration command for your version.
- Does this package run in production or is it require-dev only?
- It is a testing and benchmarking utility, so the intended placement is require-dev with execution at test or CI time. That keeps it out of the request path with no production runtime footprint, no schema changes, and no service-contract implications. Adoption is reversible by removing the dev dependency, though you should confirm in composer.json that no service provider registers in production.
- How does the built-in route discovery and CSRF handling work?
- Route discovery lets you point the package at your application's routes so you do not have to hand-write every endpoint in a scenario. CSRF handling is built in as well, which matters because Laravel's default web middleware stack rejects unsigned POST requests and would otherwise distort your measurements. Together they cut the boilerplate needed to get a realistic VoltTest scenario running against a real Laravel app.
- Can I assert on response times and database query counts in my tests?
- Yes. You define scenarios, run them through the VoltTest PHP SDK, and set assertions on measured response times and database query counts. That lets slowdowns and regressions fail the suite in CI instead of reaching production. Because assertions are threshold-based, pick tolerances that absorb normal runner variance rather than tight numbers that flake.
- Which PHP, Laravel, and PHPUnit or Pest versions are supported?
- The package is a Laravel testing utility driven by PHPUnit or Pest, and v1.3.3 fixes a PHP 8.4+ deprecation surfaced by the server health check while extending the CI matrix to PHP 8.5. Behavior on PHP 8.3 and below should be unchanged. The Laravel major-version range and exact PHPUnit and Pest coverage are not evidenced in the release notes, so verify them in composer.json before adopting.
- Do the health checks hit real databases, caches, or queues in CI?
- Health checks can touch real dependencies such as the database, cache, queue, and outbound HTTP, which makes results environment-dependent if those probes reach live infrastructure. Point them at a controlled test environment, and disable or stub any probe you do not want exercised. Whether each probe can be toggled individually should be confirmed in the package documentation for your version.
- How do I keep performance tests from becoming flaky on shared CI runners?
- Threshold-based performance tests are a known source of flake on noisy shared runners, so run them on dedicated or consistently sized machines. Keep thresholds loose enough to absorb normal variance and treat the assertions as regression detectors rather than precise benchmarks. Isolating health checks from live shared services also removes a large source of run-to-run variance.
- Is there a migration step from v1.3.2 to v1.3.3?
- No. There are no reported API changes, removals, or migration steps, so moving to v1.3.3 is a version bump plus a re-run of your suite. Constrain to ^1.3 so patch releases, including the PHP 8.4 deprecation fix, are picked up automatically. If your CI treats deprecations as failures, v1.3.3 is effectively required on PHP 8.4+ rather than optional.
- How does this compare with k6, Artillery, or JMeter?
- Those tools are dedicated load generators designed for throughput and soak testing from outside the application. This package runs inside your Laravel test suite, which makes it better suited to fast regression assertions on response times and query counts on every commit. Many teams use both: in-suite assertions for continuous coverage and a separate load generator for capacity planning.
- Who maintains the package and how actively is it developed?
- The v1.3.3 release is authored by a single contributor, so bus factor and long-term maintenance are the primary structural risks rather than code quality. On the positive side, extending CI to PHP 8.5 signals the maintainer is tracking upstream PHP deprecations instead of accumulating them. Review the release cadence, issue-response history, license, and security disclosure process before standardizing on it.