- What is runroom-packages/testing used for?
- It is a dev-only library of reusable PHPUnit test utilities, including base test cases, helper traits, and custom assertions, extracted from Runroom's own bundle and project test suites. The goal is to standardize how tests are bootstrapped and remove repeated setup code across repositories. It contains no runtime infrastructure, so it never ships to production. Note that the GitHub repository is a read-only split, meaning it is published from a parent monorepo rather than maintained directly on the split repo.
- How do I install runroom-packages/testing with Composer?
- Run composer require --dev runroom-packages/testing and pin an explicit constraint such as ~1.0.0 or a specific commit hash rather than a floating caret range. Because it is a test-only dependency, keeping it in require-dev lets Composer skip it entirely when generating production autoloads with --no-dev. After installing, run composer show runroom-packages/testing to confirm which PHP and PHPUnit versions it actually resolves against, since no compatibility matrix is published.
- Does runroom-packages/testing support Laravel 10, 11, or 12?
- There is no published compatibility matrix, and the package documentation frames the helpers around Runroom's bundles, which are Symfony-first rather than Laravel-first. Verify the PHP, PHPUnit, and Symfony/Laravel constraints yourself by inspecting the composer.json on the branch you intend to use or by running composer why-not. In a Laravel codebase the helper set overlaps heavily with Laravel's own TestCase, HTTP assertions, and factories, so the marginal benefit is smaller than in a Symfony project.
- Is runroom-packages/testing safe to use in production?
- It should never reach production. It is a testing utility meant to be installed with --dev and excluded from production autoload generation via composer install --no-dev. The security risk is negligible because there is no runtime code path, but the transitive dev dependencies it may pull in, including sibling Runroom packages, do enlarge your CI dependency graph for limited benefit.
- Should runroom-packages/testing go in require or require-dev?
- Always require-dev. There is no service provider, middleware, config, or runtime class an application needs at execution time, so placing it in require leaves dead weight in your production vendor directory. Combined with an exact or tilde-pinned version constraint, require-dev keeps adoption reversible: you can remove the package without touching application code.
- How is runroom-packages/testing different from Laravel's built-in testing tools?
- Laravel already ships a base TestCase, HTTP and database assertions, model factories, fakes, and first-class Pest support, which covers most of what a Laravel test suite needs. runroom-packages/testing targets Runroom's own bundle conventions, including Symfony-style kernel and container bootstrapping, so its helpers often duplicate rather than extend Laravel primitives. If you are not consuming other runroom-packages bundles, the shared conventions it encodes are probably not ones your project follows.
- Can I use runroom-packages/testing with Pest or PHPUnit 12?
- The helpers are built around PHPUnit base test cases and custom constraints, so they will not map cleanly onto Pest's functional style without adapters. PHPUnit majors land roughly annually and break test harnesses first, so check the package's composer.json for its PHPUnit constraint before upgrading your own runner. If your suite is on a PHPUnit major the package has not been updated for, copying the specific helpers you need is more pragmatic than fighting the dependency.
- Why does runroom-packages/testing have only two stars and no dependents?
- Runroom's repositories are typically read-only splits published from a monorepo, so star counts, issue activity, and release cadence on the split repo systematically understate the parent project's health. Evaluate the monorepo before concluding the package is abandoned. That said, zero external consumers means there is no community pressure to keep it current with new PHP and PHPUnit releases, so assume you are the one tracking compatibility.
- What should I do if runroom-packages/testing is unmaintained or lacks PHPUnit support?
- Because it is MIT licensed and small enough to read in under an hour, your options are to pin it, fork it, or copy the helpers you actually use into tests/Support/ with attribution. For a test utility of this size, copying is usually the best trade: it captures the full value, removes the dependency, and keeps the code inside your own upgrade cycle. Forking only makes sense if you need sustained patches and want to track upstream changes deliberately.
- How do I decide whether to adopt runroom-packages/testing at all?
- Run the fit test first: name a concrete test you cannot write today, and if you cannot, the package is not solving a problem you have. If you do consume other Runroom bundles and share their kernel and container conventions, the helpers are a reasonable require-dev addition with an exact or commit-hash constraint. In a Laravel-only codebase with no Runroom bundles, the overlap with native tooling is high and the marginal utility is low.