Unit Test Generator Laravel Package

Getting Started

The package is a low-footprint scaffolding tool from the micro-module/* family — its job is to generate unit-test stubs (PHPUnit or Pest) for classes so you don't hand-write boilerplate. Because it's a scaffolding utility rather than a runtime dependency, "getting started" is short and its blast radius on your app is small.

Install

composer require --dev micro-module/unit-test-generator

Pin it ("micro-module/unit-test-generator": "^1.0") and commit the lockfile. The last tagged release is from July 2023, so expect to run composer update --with-all-dependencies if your app is on Laravel 11/12 or PHP 8.3+.

Where to look first

1. php artisan list — the package's real surface area is its Artisan commands. Filter with php artisan list | grep -i test to find the generator entry point (likely namespaced under module: or make:).
2. config/unit-test-generator.php (after php artisan vendor:publish --tag=unit-test-generator-config) — namespaces, output paths, and stub selection usually live here.
3. The stubs/ directory in vendor/ — this is what you'll actually customize. Read the shipped stub before generating anything so you know what you're getting.
4. The service provider (src/…ServiceProvider.php) — confirm whether it registers commands unconditionally or only in non-production environments.

First use case

Generate a test stub for one existing class end-to-end before wiring it into any workflow:

php artisan <generator-command> App\\Services\\InvoiceCalculator

Then open the generated file, confirm the namespace/class name resolution is correct, add one real assertion, and run php artisan test --filter=InvoiceCalculatorTest. If that round-trip works, the package is usable for you; if namespaces are mangled, stop and fix the config before generating in bulk.

Implementation Patterns

Scaffold-then-fill in the same commit. The realistic value is not "tests get written for you" — it's "the boring 80% of a test file appears instantly." The pattern that works:

1. Generate the test alongside the class you just wrote (or immediately after make:model/make:action).
2. Replace the stub's markTestIncomplete() / commented-out $this->assertTrue(true) with one behavior.
3. Commit both files together so review always sees test + code as a pair.

Chain it into your module scaffolding. If you're already using the micro-module/* family to scaffold modules, alias the generator next to your make: commands in a script:

php artisan module:make Action Billing/ChargeCustomer
php artisan <generator-command> Modules/Billing/Actions/ChargeCustomer

This is where the package earns its keep — as one line in your scaffolding script rather than a command you remember to run.

Publish and own the stubs. Don't edit files in vendor/. Publish the stubs to stubs/unit-test-generator/ and point the config at your copies. Then standardize on what a "good test file" looks like for your team: your base TestCase, your factories/traits, your RefreshDatabase (or deliberately not), and a Pest it() shape if that's your flavor. Every generated test then starts at 40% instead of 5%.

Separate Unit and Feature targets. Most micro-module generators let you choose test type. Map it to your directories explicitly in config (tests/Unit vs tests/Feature) rather than relying on defaults — the default inference for "is this a unit or feature test" is usually naive (namespace-based), and you'll get Feature tests that use RefreshDatabase on pure value objects.

Keep it out of production installs. It should be --dev and (ideally) gated behind app()->environment() !== 'production' in the service provider. Verify this rather than assume it, since a 2023 single-maintainer package may register commands unconditionally.

CI integration is minimal by design. There's nothing to integrate: the package never runs tests, it only writes files. Your CI story is unchanged — php artisan test — you just have more files to run it against.

Gotchas and Tips

Be honest about the maintenance math. One star, zero dependents, last release mid-2023. Treat this as vendored convenience code, not infrastructure. Two concrete consequences: (a) if it breaks on a future Laravel upgrade, you fix it yourself, and (b) don't block a composer update on it — if it conflicts, fork it or drop it. Have a plan for both before adopting.

Verify compatibility before bulk use. Run the smoke test from Getting Started on your actual PHP/Laravel versions first. Common breakage points: string-based Str/Arr helpers deprecated in Laravel 10/11, Illuminate\Console\Command signature changes, and PHP 8.3+ typed-class-constant deprecations in stubs.

Namespace resolution is the failure mode. Generators that take a class name (rather than a path) guess your PSR-4 root from composer.json. In a modular app with multiple PSR-4 roots, that guess is often wrong and you get a test in tests/Unit with namespace Tests\Unit; when you wanted Modules\Billing\Tests. Fix it in config, or pass paths instead of class names if both are supported.

Generated tests are scaffolding, not coverage. A codebase full of stub tests will pass CI while testing nothing, which is worse than no tests (it inflates coverage metrics and hides untested code). Enforce a rule: a generated test that still contains markTestIncomplete() fails review. Better yet, grep CI for it:

! grep -r "markTestIncomplete" tests/

Don't generate tests for trivial code. Getters, DTOs, and Eloquent models with no logic are the classic trap — the generator makes it free to create a test file, so people create hundreds of them. Reserve the tool for classes with branches, calculations, or collaborators worth mocking.

Extension points, if you need them. The stub directory is the primary knob. Beyond that, look at whether the command accepts options for namespace/path overrides — if the config plus stubs can't express your convention, you're better off writing a 20-line custom Artisan command than patching this one. At this package's size, forking is often cheaper than working around it.

Debugging a bad generation. If the output is wrong, run with -vvv, then read the command class directly (vendor/micro-module/unit-test-generator/src/Commands/*.php) — at this scale the whole package is a few hundred lines and reading it takes less time than guessing. Check config() values are actually loaded (php artisan tinker → config('unit-test-generator')) before assuming a bug.