Factory Generator Laravel Package

Product Decisions This Supports

• Build vs. buy for test-coverage retrofits: Factory Generator is a developer-facing codegen tool that inspects your existing database schema and models, then emits Laravel model factories populated with plausible fake data. Choosing it replaces days of hand-writing factories with a single command, which is a low-cost way to unblock a testing initiative on a legacy codebase.
• Roadmap sequencing for a "make the codebase testable" epic: Because factory generation is a prerequisite for feature tests, this package is best positioned as an accelerant for the first sprint of a test-coverage workstream, not as an ongoing product dependency.
• Use-case fit: Strongest when you have a wide, messy schema (dozens to hundreds of tables), no factories, and a mandate to add integration/feature test coverage before a migration, upgrade, or handover.
• Release signal — maintenance: v2.3 adds Laravel 13.x compatibility only (PR #36). This is a support-matrix widening with no new features, no deprecations, and no breaking changes. For planning purposes it confirms upstream maintenance is active and that the tool keeps pace with framework majors — a favorable signal when deciding whether to standardize on Laravel Shift tooling.
• Cost floor is near zero: It is a dev-only dependency. Adoption does not touch production runtime, deployment artifacts, or customer-facing behavior, so the decision can be made by engineering without commercial review.

When to Consider This Package

Consider adoption when:

• You have an existing Laravel application with a substantial, stable schema and few or no existing factories.
• The team is about to invest in feature/integration test coverage and wants a fast starting point rather than a blank-page effort.
• You are on a supported Laravel version — v2.3 explicitly covers up to Laravel 13.x. Confirm your PHP version against the package's composer constraints before committing.
• Generated factories will be treated as a scaffold: reviewed, corrected, and then owned by the team (relationship handling, enums, custom casts, and domain-specific states generally need human edits).
• You already use, or are open to, Laravel Shift tooling and conventions.

Look elsewhere when:

• The project is greenfield, the schema is small, or factories already exist — hand-written factories will be clearer and cheaper.
• The schema relies heavily on bespoke value objects, custom casts, polymorphic or non-standard foreign keys, or multi-tenant scoping that codegen cannot infer correctly; cleanup cost can exceed savings.
• You need factories as long-lived, hand-maintained fixtures with rich named states — this tool bootstraps, it does not manage.
• You require an SLA or vendor support contract; this is a single-maintainer open-source package.
• You are pinned to a Laravel version outside the supported matrix (v2.3 is the first release to declare 13.x; older tags will not cover it).

How to Pitch It (Stakeholders)

For executives: This is a free, development-only utility that generates test fixtures automatically from our existing database structure. It compresses the slowest, least differentiated part of a testing initiative — writing boilerplate setup code — into a single command, letting the team reach meaningful test coverage sooner and at effectively no procurement or runtime risk. The v2.3 release shows the maintainer is actively tracking new Laravel versions, so the tool is not abandoned.

For engineering: laravel-shift/factory-generator reverse-engineers your tables and models into factories. Add it as a require-dev dependency, run the generator, then review and harden the output. v2.3 is a maintenance release: added Laravel 13.x compatibility (PR #36), nothing else — no breaking changes, no deprecations, so an upgrade from v2.2 is a no-op beyond the version constraint. Treat generated factories as a one-time scaffold committed to the repo and owned thereafter; the package is not a runtime or production dependency, and removing it later costs nothing.