Filament Tests Laravel Package

Technical Evaluation

Architecture fit. codewithdennis/filament-tests is a dev-time scaffolder, not a runtime dependency. It sits in require-dev alongside pestphp/pest and filament/filament, introspects Filament resource classes, and emits PEST test files under tests/. No production code path imports it, so architectural coupling is effectively zero and removal is a composer remove plus a file cleanup. That matters for how a TPM frames the decision: this is a bounded, reversible engineering experiment, not a platform commitment. The question to answer is "do we want the output?" — not "do we want this in our stack?"

The strategic value is concentrated in what it removes. Filament resources — forms, tables, actions, policies, relation managers — are typically the least-covered part of a Laravel codebase because authoring those tests by hand is tedious and low-glamour. A generator that turns per-resource test authoring into a scaffolding pass changes the cost curve on "should we test the admin panel?" from weeks to days. That is the product decision this package supports, and it is the reason to spend any time on it despite the health signals.

Integration feasibility. High for a spike, conditional for anything longer. Prerequisites are narrow and well understood: a Laravel app using Filament, with PEST installed or installable. Input is a resource class; output is a test file. That flow is easy to prototype and easy to reason about. The real feasibility question is not installation but whether the emitted tests still run green against the current Filament major and PEST major — Filament's testing surface (Livewire component assertions, table/form/action helpers) has moved materially across v2 → v3 → v4, and PEST's syntax has moved with its own majors. Feasibility is gated on a version-resolution check and an observed pass rate on representative resources, not on the README.

Technical risk. Three areas dominate:

• Staleness. Archived repo, ~99 stars, zero dependents, single-maintainer history. Any Filament or PEST release after the archive date is unvalidated by definition, and there is no upstream path to a fix. For any org with dependency approval, SBOM, or security review, archived status is a hard blocker as a standing dependency — which is why the recommendation is harvest-or-fork, not adopt.
• Output rot. The deliverable is static test source. Those files do not upgrade themselves; once generated they are hand-maintained artifacts pinned to a specific Filament testing API, drifting as both framework versions and the resources themselves change.
• Coverage assumptions. Generated assertions reflect what the generator author considered worth asserting — typically render and validation basics. Treating them as a safety net without reading them risks false confidence, especially around actions, bulk actions, relation managers, authorization matrices, and tenant-scoped panels.

Counterweight: blast radius is bounded. As a dev-only dependency it cannot break production, and the exit cost is a composer entry plus optional file cleanup.

Documentation flag for the PM. The package description ("creates PEST tests tailored for your Filament resources") and the documentation (a test-runner page inside the Filament dashboard) describe two different products. Confirm which artifact is being evaluated before committing scope. That ambiguity alone justifies a timeboxed spike rather than a plan.

Key questions for the spike owner.

1. Which Filament and PEST majors are supported per composer.json and CI matrix, and does that resolve cleanly against our composer.lock?
2. What is the last commit date relative to archival, and is there a tagged release usable under an exact pin?
3. Does it emit runnable tests or scaffolds requiring manual completion — and what percentage passes green unmodified on three representative resources (simple CRUD, one relation manager, one with actions and custom form components)?
4. Does it cover actions and bulk actions, or only table columns and form schema?
5. Is resource introspection reflection-based (fragile to Filament internals) or convention-based?
6. How does it handle wizards, custom Livewire components, and multi-panel/tenant scoping?
7. Do the generated tests catch a seeded regression, or only assert that pages render?

Integration Approach

Stack fit. TALL stack — Laravel 10/11, Livewire 3, Filament 3, PEST 2/3 on PHPUnit 10/11. The package belongs in require-dev only, pinned to an exact version, and must never be promoted into require. Sequencing note: if the team is not already on PEST, adopting PEST is the larger and more durable decision. Sequence PEST adoption first; evaluate this package as a downstream convenience, not as the driver.

Migration path. Given archived status, the correct framing is adopt the output, not the dependency:

1. Spike. Install on a throwaway branch against three representative resources.
2. Harvest. Run the generator, commit the emitted tests, remove the package, re-run the suite. This measures the genuine deliverable — test files that stand on their own.
3. Decide. If output quality clears the bar, keep the tests and drop the dependency. If generation is a recurring need (many resources in flight, ongoing admin growth), fork the generator into an internal tools/ package or monorepo packages/ directory we own and can patch against future Filament versions.
4. Reject the third path — carrying the archived package as a live require-dev dependency and expecting it to survive Filament upgrades. That is the option that quietly blocks composer update for the whole team.

Compatibility. Pin to the last released tag; verify Filament and PEST constraints resolve before writing code. Review the lockfile diff — a dev dependency can still pull transitive packages. Confirm generated tests execute under the same PHPUnit configuration, test database, and RefreshDatabase/factory setup as the rest of the suite; Filament resource tests are stateful and surface environment assumptions immediately.

Sequencing (TPM view).

• Week 0: confirm Filament/PEST versions and resolution; select the three sample resources; name the spike owner.
• Week 1: spike, harvest, remove the dependency. Measure generated-test pass rate and lines needing manual repair.
• End of Week 1: go/no-go — adopt output, fork generator, or discard with a written note on what an in-house generator would need to do.
• Week 2 (if go): roll generated tests across the resource inventory in reviewed batches; wire into CI as a required check so the tests are enforced rather than decorative.
• Ongoing: assign a named owner for the harvested files; treat them as first-class code under normal review.

Roadmap tie-in. The highest-value moment to run this is immediately before a risky change — a Filament major upgrade (v3→v4), a Laravel major bump, or a refactor of resource classes — not after. Position it as a quality-gate input to that sequencing decision, not as a general test-coverage initiative.

Operational Impact

Maintenance. Upstream maintenance is zero. Archived repos receive no fixes and no issue triage. Our maintenance load is entirely the generated tests, which we own the moment they are committed. The package is a one-shot accelerator: it front-loads authoring effort and contributes nothing thereafter. Budget accordingly, and do not plan on "regenerating tests after a Filament upgrade" unless we fork.

Support. No vendor, no SLA, no maintainer responsiveness. Internal ownership must be explicit before adoption, because a package with no owner becomes unowned test scaffolding that either fails silently in CI or gets skipped. The realistic support model is one engineer who understands Filament's testing helpers and can repair generated assertions as the framework evolves.

Scaling. Generation scales linearly and cheaply with resource count. The tail is the problem: each generated test is a maintenance liability proportional to how tightly it binds to Filament internals. At ~10 resources this is a clear win; at 100, hand-maintaining generated assertions across Filament majors becomes a project in itself. Set a threshold in the spike — if the admin surface is expected to grow past a few dozen resources, favor forking the generator (repeatable) over harvesting once (point-in-time).

Failure modes.

• Silent rot: generated tests keep passing because they assert only that a page renders, while actions and authorization go untested. Mitigate by seeding a deliberate regression during the spike and confirming a test fails.
• Skip creep: brittle tests on customized resources get marked skipped and never revisited. Mitigate by tracking skipped-test count as a review metric.
• Upgrade blocker: the archived package stays pinned in require-dev and constrains a future Filament upgrade. Mitigate by removing the package at harvest time — the single most important operational rule here.
• Environment mismatch: stateful Filament tests fail in CI due to database or tenancy setup, eroding trust in the suite. Mitigate by validating in CI during week 1, not after rollout.
• False coverage signal: stakeholders read "tests exist" as "admin panel is safe." Mitigate with a one-page statement of what the generated tests do and do not assert.

Ramp-up. Low for a PEST-fluent engineer — install, point at a resource, read the output. The real learning is in reviewing generated assertions critically, which requires familiarity with Filament's testing helpers (Livewire assertions, callAction, table/form schema tests). Plan for roughly a day of ramp-up before the spike's measurements are trustworthy, and capture the spike findings as a short internal note so the next engineer does not repeat the evaluation if the decision is "fork later."

Bottom line for the PM. Fund a one-to-two day timeboxed spike with a named owner and a go/no-go date. The downside is two engineering days and a discarded branch; the upside is either regression safety on the admin panel ahead of the next Filament upgrade, or a precise specification for the ~200-line generator we would build instead. Either outcome is worth the cost — provided the package itself does not survive the spike as a dependency.