Phpunit Skeleton Generator Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow (and the answer is usually "neither"): This package answers a narrow question — "should we write our own scaffolding tool to turn classes into test skeletons?" It is a reference implementation of that idea, not a dependency to adopt. Use it to inform a decision, not to ship code.
• Test-coverage ramp-up strategy: If a roadmap item is "raise coverage on a legacy module from ~10% to a target threshold," skeleton generation is one lever. This package demonstrates the ceiling and the limits of that lever: it produces shape, not assertions, so it accelerates the first 20% of test writing and none of the valuable 80%.
• TDD / testing-culture adoption: Useful as a discussion artifact when deciding whether to invest in tooling (generators, IDE live templates, mutation testing) to lower the activation energy for engineers writing their first test in an unfamiliar service.
• Onboarding and developer-experience roadmap: Informs whether to invest in editor tooling (PHPStorm test-generation templates, Pest's --test/conversion commands, php artisan make:test) versus a standalone CLI. The editor-integrated path is almost always the better product bet.
• Deprecation and dependency-hygiene policy: With a score of 0, zero dependents, and an unmaintained status, this is a concrete example for a "no new unmaintained dependencies" policy — good input for an engineering-standards decision rather than a feature decision.
• Not a differentiator: Nothing here creates user-facing value. It should not appear on a customer-facing roadmap; at most it is an internal engineering-enablement line item with a low priority.

When to Consider This Package

Consider it (as a reference, rarely as a dependency) when:

• You are pinned to PHP 7.x with PHPUnit 6/7 and have an accepted, time-boxed need to bulk-scaffold test classes across a large legacy codebase where no IDE tooling is standardized.
• You want to study the inverse direction (generating a production class skeleton from a test) for a code-gen experiment, and prefer reading prior art over designing from scratch.
• You are evaluating whether to build an internal generator, and need a concrete baseline for effort, output quality, and maintenance burden.
• You need an offline/CI-embedded generator in an environment where editor plugins are unavailable (rare, and usually solvable another way).

Look elsewhere — decisively — when:

• You are on Laravel 9/10/11 with PHPUnit 9/10/11 or Pest. The PHPUnit TestCase API, namespaces, and configuration format have moved on; a generator targeting the PHPUnit 6 era will emit skeletons that do not run without manual repair. The generated code becomes a maintenance liability rather than a saving.
• You need maintained, security-reviewed dependencies. Zero stars, zero dependents, and an inactive repository mean no upstream fixes, no compatibility patches, and no CVE response.
• Your goal is behavioral coverage. Skeleton generators emit empty or trivially-failing tests; they do not produce meaningful assertions, fixtures, or data builders. For Laravel, factories, RefreshDatabase, and HTTP test helpers deliver far more per engineer-hour.
• The need is one-off. php artisan make:test, IDE generation, or a five-line script covers it without adding a dependency to composer.json.

Recommendation: Do not adopt. Record it as prior art, and if scaffolding is a real pain point, resolve it through IDE templates and framework-native generators first; revisit only if those measurably fail.

How to Pitch It (Stakeholders)

For executives: We evaluated a test-skeleton generator for the legacy-modernization workstream. It is a small, unmaintained utility with no downstream users and no compatibility with our current PHP and PHPUnit versions. Adopting it would add a dependency we would have to fork and maintain ourselves, in exchange for generating empty test stubs — the low-value part of test writing. My recommendation is to skip it and put the same effort into editor-integrated generation and framework-native test scaffolding, which cost nothing to own. Net: no roadmap change, no budget request.

For engineering: This is prior art for class-to-test and test-to-class generation, written for the PHPUnit 6 era. The output is a compiling stub with no assertions, and it will not target current PHPUnit namespaces or attributes. If scaffolding friction is real, the cheaper path is IDE file templates plus make:test, with a thin internal script if we need batch generation against our own conventions. If we do want a generator, treat that as a small internal tool with an owner — not a third-party dependency with no maintainers.