- What does codewithdennis/filament-tests actually do?
- The package is described two ways in its own materials: the overview says it generates Pest tests tailored to your Filament resources, while the README and blurb describe a panel page that runs and reviews your PHPUnit or Pest suite from inside the Filament dashboard. Confirm which artifact you are evaluating before you scope any work. Either way it is a dev-time tool with no runtime code path in production.
- Does it generate tests or run them?
- Both capabilities appear in the package's documentation, which is a real ambiguity rather than a feature list. Read the source and README of the specific tagged release you intend to use to see which one actually ships. Treat the generator and the panel runner as separate evaluation targets with separate value.
- How do I install it in a Laravel app?
- Require it with Composer in require-dev alongside filament/filament and pestphp/pest, then follow the README for any panel registration or publish step. Because it is a dev-only dependency, it should never be part of a production build installed with --no-dev. Confirm the exact artisan command names in the README rather than guessing them.
- Which Filament and Pest versions are supported?
- Filament's testing surface, including Livewire component assertions and table, form and action helpers, has moved materially across v2, v3 and v4, and Pest's syntax has moved with its own majors. Check composer.json and any CI matrix in the repository, then verify the constraints resolve cleanly against your composer.lock. Do not assume the compatibility claims still hold now that the repository is archived.
- Is the package still maintained?
- Health signals indicate it is archived, with roughly 99 stars, zero dependents and a single-maintainer history. Anything released by Filament or Pest after the archive date is unvalidated by definition, and there is no upstream path to a fix. For organizations with dependency approval or SBOM review, archived status is typically a hard blocker for a standing dependency.
- Is it safe to use in a Laravel production application?
- It cannot break production because it is a dev-only dependency and no production code path imports it. The real risks are staleness and output rot, since the generated test files are static artifacts that do not upgrade themselves. Keep it in require-dev under an exact version pin and treat the emitted tests as code you own.
- Does it cover relation managers, actions, bulk actions and authorization?
- Generated assertions reflect what the generator author considered worth asserting, which is typically render and validation basics. Actions, bulk actions, relation managers, tenant-scoped panels and policy matrices are the areas most likely to be thin or missing. Read every generated test before relying on it, or you risk false confidence in exactly the parts of Filament that break most often.
- Can I run the generated tests in CI?
- Yes, indirectly: the files it emits are ordinary Pest or PHPUnit tests, so they run wherever your suite already runs. The in-panel runner is a developer convenience, not a CI mechanism. Pin the package version so regenerated output stays consistent across machines.
- What are the alternatives to this package?
- Filament ships its own testing helpers for Livewire component assertions, and Pest plus Laravel's HTTP and database testing cover the rest, which is precisely why hand-written resource tests feel tedious. The package's value is removing that authoring cost, not adding a capability you cannot get elsewhere. If it goes stale, harvest the generated patterns into your own test base class or fork the generator.
- How hard is it to remove if we change our minds?
- Removal is a composer remove plus cleanup of any generated test files you no longer want to keep. No production code path imports it, so architectural coupling is effectively zero. That makes it a bounded, reversible engineering experiment rather than a platform commitment.