Laravel Factory Generator Laravel Package

Product Decisions This Supports

• Test-coverage roadmap bets. The bulk of the cost in backfilling tests on an existing Laravel app is boilerplate factory scaffolding, not test design. This package turns that from days of grunt work into a generator run, which changes the calculus on "can we afford to raise coverage from X% to Y% this quarter?" — the answer becomes about engineer time allocation, not raw effort.
• Legacy modernization sequencing. If the roadmap includes a Laravel/PHP upgrade, factory generation is a low-risk prerequisite step: it makes the existing behavior testable before you touch framework versions. The 1.5.0 enum hardening matters here specifically, since enum-heavy models are exactly what you hit when moving to PHP 8.1+ / Laravel 9+.
• Build vs. buy (build vs. adopt). Nothing here is differentiated IP. Writing an in-house factory generator is a classic case of spending engineering cycles on solved commodity tooling. Default position should be: adopt, pin, move on.
• Developer onboarding and inner-loop speed. New hires and prototypes get realistic model factories without reverse-engineering every schema by hand. That is a measurable ramp-time lever on teams with churn or frequent spikes.
• CI and PR hygiene. The new --dry-run mode is the decision-relevant feature for process: you can preview generation output in a pipeline or a PR without mutating the working tree, which makes it safe to standardize as a repeatable step rather than a one-off local trick.
• Risk posture on dev-only dependencies. 1.5.0 ships a real test suite and fixes a crash when the factories directory is missing — the exact failure mode in fresh repos and freshly cloned legacy projects. That materially lowers the "will this embarrass us in CI" risk that previously argued for caution.

When to Consider This Package

Adopt when:

• You have an existing Laravel app with a meaningful number of Eloquent models and thin or absent factory coverage — especially a legacy or acquired codebase where nobody remembers the schema intent.
• A coverage, testing, or framework-upgrade initiative is on the roadmap and needs to move this quarter.
• Your models lean on PHP enums, since 1.5.0 hardens the enum driver — this is the release that makes enum-heavy codebases a supported case rather than a gamble.
• You want a previewable, non-mutating generation step in CI (--dry-run) so output can be reviewed like any other generated artifact.
• You need demo/seed data quickly for prototypes, sales demos, or staging environments.

Look elsewhere or skip when:

• The team is test-first and writes factories by hand as part of normal TDD — the generator's output will be replaced anyway.
• Schemas are highly non-standard: custom casts, polymorphic or non-convention relations, non-Eloquent persistence. Generators infer from convention; where convention doesn't hold, you'll spend as long correcting output as writing it.
• You can't tolerate a single-maintainer dev dependency. Mitigate with lockfile pinning and reviewing generated diffs rather than avoiding it outright, but if your supply-chain policy forbids it, that's a hard stop.
• You expect the tool to also generate tests, not just factories — it doesn't, and shouldn't be pitched as a coverage solution on its own.
• You need production-runtime behavior. This is dev tooling only; it has no place in a runtime dependency list.

How to Pitch It (Stakeholders)

For executives: This is a small, free developer tool that removes the most tedious part of writing automated tests for our Laravel application. The practical effect is that a testing or platform-upgrade initiative becomes cheaper in engineer-hours without adding headcount, and it carries no production risk because it never ships to customers. The 1.5.0 release is the one that makes it dependable: the maintainer added an automated test suite, fixed a crash that hit fresh repositories, and added a safe preview mode so output can be reviewed before anything is written. Recommend adopting it as a pinned developer dependency, with the caveat that it is maintained by a single author — which is acceptable for tooling that only runs on developer machines.

For engineering: Version 1.5.0 is the first release I'd call safe to standardize on. Concretely: a real test suite now exists, the missing-factories-directory crash is fixed (the failure you'd otherwise hit on every fresh clone), the enum driver is hardened for modern Laravel/PHP, Faker usage is modernized, and --dry-run lets you preview output — so you can wire it into CI or a PR review step without it silently rewriting files. Treat generated factories as a starting draft, not final code: expect to hand-edit custom casts, non-convention relations, and polymorphic associations. Pin the version in composer.lock, keep it in require-dev, and review generated diffs like any other generated artifact.