What the agent does
The agent maps the panel's classes to the tests that exist before writing any, so it fills gaps rather than duplicating coverage. In filamentphp/demo, composer.json requires filament/filament ^5.0 on laravel/framework ^12.0 with pestphp/pest ^3.0, and app/Filament/Resources holds 15 resources across Blog, HR and Shop. Every resource page already has a test under tests/Filament/Resources, from CreateBrandTest to ViewLeaveRequestTest. The gap is in relation managers: there are 12 under RelationManagers/ directories, and only one, Shop/Products/RelationManagers/CommentsRelationManager, has a test.
So the run's work list is the other 11: AddressesRelationManager and PaymentsRelationManager on customers, PaymentsRelationManager on orders, ProductsRelationManager on shop categories, AddressesRelationManager and ProductsRelationManager on brands, TasksRelationManager and TimesheetsRelationManager on projects, EmployeesRelationManager on departments, and LeaveRequestsRelationManager and TimesheetsRelationManager on employees. For each it reads the class's form() and table() to list the fields, validation rules, filters and actions it defines.
It writes the tests in the style the suite already uses. tests/Pest.php extends TestCase, uses RefreshDatabase and logs in a fresh User before every test in Filament, and CommentsRelationManagerTest mounts a manager with Livewire::test(CommentsRelationManager::class, ['ownerRecord' => $product, 'pageClass' => EditProduct::class]) and creates records with callAction(TestAction::make('create')->table(), [...]). Each new file follows that: it renders, the table lists the owner's related records and not another owner's (assertCanSeeTableRecords and assertCanNotSeeTableRecords), the create action saves with valid data and fails with assertHasFormErrors on each required field, edit and delete actions change the database, and each filter narrows the rows. Records come from the model factories under database/factories.
It prepares the environment the way .github/workflows/tests.yml does: PHP 8.4 with pdo_sqlite, cp .env.example .env, composer install, npm ci && npm run build, php artisan key:generate and an empty database/database.sqlite. Then it runs composer test:pest, which is pest --parallel, until the suite passes, and runs it again to make sure no new test depends on parallel ordering.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Write Pest tests with Filament's Livewire testing helpers for the parts of this panel that have none. First list every resource page and relation manager under app/Filament and the tests under tests/Filament, and work only on the ones without a test. For each relation manager, mount it with Livewire::test(..., ['ownerRecord' => ..., 'pageClass' => ...]) like CommentsRelationManagerTest and cover: it renders, the table shows only the owner's records, create with valid data and with each required field missing, edit and delete actions, and each table filter. Use the model factories. Set up the environment as .github/workflows/tests.yml does, run composer test:pest until it passes, and open a pull request.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The pull request adds one test file per untested relation manager, each at the path that mirrors its class, for example tests/Filament/Resources/Shop/Orders/RelationManagers/PaymentsRelationManagerTest.php and tests/Filament/Resources/HR/Employees/RelationManagers/LeaveRequestsRelationManagerTest.php. If a model the tests need has no factory state for a case, such as a payment in a particular status, it adds that state to the factory and says so. Nothing under app/ changes.
The description has a table of the 11 relation managers with the cases covered for each, quotes the pest --parallel summary from the sandbox run, and lists anything it could not test with the Livewire helpers, with the reason. The repository's tests workflow runs the same command on the pull request, and the session's record keeps each run the agent made, including failures it fixed along the way.
A reviewer checks that each validation case matches the rule in the manager's form(), that the scoping test really creates a record on a second owner, and that the suite is still green under composer test, which also runs phpstan analyse over the new files.
Run it on every Filament resource added
Filament makes it quick to generate a resource or relation manager with php artisan make:filament-resource, which is also how panels end up with untested ones. A GitHub trigger on pull_request.opened can run this request on every pull request that adds files under app/Filament, asking for tests of the new classes in the same style, so new admin screens arrive tested.
A weekly schedule trigger works too, for teams that prefer one pull request of tests on a Monday morning: the prompt asks for every resource, page and relation manager added since the last run that has no test file at its mirrored path.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Running a Filament suite needs PHP 8.4 with the right extensions, a Composer install, a Vite build of the panel assets and a database, and pest --parallel uses every core it can find. In a Rush sandbox the agent sets all of that up from the workflow file, runs the suite as often as it takes, and leaves your local PHP and database alone.
The tests are proven by their runs: the Pest output in the session's record, and the repository's own workflow on the pull request. Writing 11 relation manager tests is repetitive work that is easy to review and slow to type, and on Rush it happens while you do something else, with one pull request to read at the end.
Frequently asked questions
Does it use Pest or PHPUnit?
Whatever your suite uses. The Filament demo uses Pest 3 with tests/Pest.php setting up RefreshDatabase and an authenticated user, so the new files are Pest tests that rely on that. In a PHPUnit project the agent writes test classes extending your TestCase instead.
Which Filament version do the helpers target?
The one in your composer.lock. Filament 4 and 5 test table actions with TestAction::make(...)->table(), as the demo's existing test does, while Filament 3 uses callTableAction. The agent reads your existing tests and the installed version and writes the matching calls.
Will it test multi-tenant panels?
Yes, if your panel uses tenancy. It sets the current tenant the way your existing tests do, and adds a case that a record from another tenant does not appear, which is the scoping check that matters most in a tenant panel.
Will it change my resources to make them testable?
No. If a manager cannot be tested without a change, such as a missing factory relation, it changes the factory, not the resource, and anything that would need application code is listed in the pull request instead.