joshbonnick/filament-faker
A Filament plugin that brings FakerPHP into your admin panel, letting you generate realistic fake data for forms, tables, and seeders. Populate fields and test resources with random names, emails, dates, and more without leaving Filament.
joshbonnick/filament-faker is a developer-convenience package: it generates fake data for Filament form schemas so you stop hand-writing fake() calls for every field in tests, seeders, and local demo screens.
Minimal setup:
composer require joshbonnick/filament-faker --dev
Install it as a require-dev dependency — it's a development/testing aid, not something your production forms should depend on.
Where to look first:
First use case — the one that pays for itself immediately: filling a Filament resource form inside a Livewire test.
Livewire::test(CreatePost::class)
->fillForm(fakeFormData(PostForm::class))
->call('create')
->assertHasNoFormErrors();
Even if you only adopt it for that, it removes the most tedious, most brittle part of Filament test suites — the fixture array that breaks every time someone renames a field.
Test fixtures instead of literal arrays. The core workflow is replacing hand-maintained fillForm([...]) arrays with generated data. Keep your assertions on the fields that matter (validated rules, required relationships, side effects) and let the faker handle the noise. Tests stay green through form churn because they no longer enumerate every field.
Schema-driven, not model-driven. Point the faker at the form schema class/component tree rather than the Eloquent model. The form is the contract your test exercises; the model may accept columns the form never exposes, and the form may expose fields that aren't columns (computed fields, dehydrated(false) fields).
Override selectively. Generate the bulk, then merge your deliberate values on top:
$data = array_merge(fakeFormData(PostForm::class), [
'status' => 'published',
'author_id' => User::factory()->create()->id,
]);
This is the right shape for nearly every real test: faker for the 20 boring fields, explicit values for the 2 the test is actually about.
A local "fill with fake data" action. In a local-only panel or a debug toolbar action, wire the faker to a form's fill() so you can populate a long form in one click while developing. Gate it behind app()->isLocal() — this is the single highest-leverage day-to-day use, especially on forms with many nested repeaters or wizard steps.
Seeders and demo environments. Combine with factories for parent records, then use the faker for the form-shaped payload. Useful for reproducing bug reports quickly on a fresh database.
Nested structures. Repeaters, builders, and ->relationship() fields are where generic fakers usually stop being useful. Check what the package does with them before relying on them in tests — you'll often still need to supply relationship IDs or repeater counts yourself.
Stay on require-dev. If this lands in production dependencies it will be autoloaded in prod and may pull in Faker as a hard requirement. Confirm it's in require-dev and that your deploy doesn't run composer install --dev.
v1.1.1 is a no-op upgrade. The only change is applying formatting hooks (PR #26). No API, behavior, or config changes — a safe patch bump with nothing to migrate. If you're already on 1.1, upgrading is optional housekeeping.
Generated data isn't valid data. Fake strings will fail your unique, exists, in, and regex rules unless the package knows about them. Expect to override validated fields explicitly rather than trusting the generator — and treat a green test that only passed because the faker happened to produce a valid value as a latent flake.
Faker's unique() state persists across a test process. Long-running suites (or Pest datasets) can hit OverflowException on unique generators. Seed or reset Faker in a setUp if you see intermittent exhaustion failures.
File uploads and rich text. Upload fields generally can't be satisfied by strings — you'll get a validation error rather than a working upload. Use UploadedFile::fake() overrides for those, plus for RichEditor/MarkdownEditor fields where you care about content.
Field-name heuristics are the extension point. The package's value comes from mapping names like email, name, published_at to sensible fakers. When a domain field falls through to a generic string, the right fix is the package's config/mapping rather than sprinkling overrides through every test — do it once, centrally.
Pin and verify Filament compatibility. This is a thin wrapper over Filament's form internals, so Filament minor upgrades can break it before the package catches up. Pin it in composer.json, and when you bump Filament, run your form tests first — they'll surface incompatibilities immediately.
Watch for silently skipped fields. If a component type isn't recognised, the faker may omit the key entirely rather than error. Assert that the generated array covers your required fields once, in a single meta-test, so a Filament upgrade can't quietly reduce coverage.
How can I help you explore Laravel packages today?