[8.x] Adds --test and --pest options to various make commands

[lukeraymonddowning]

Howdy all!

Hot off the back of #38966, this PR adds a new, simple method of adding matching tests to various GeneratorCommands in the framework, such as make:model, make:controller and make:job.

Usage

To generate a matching test, simply use the --test option for PhpUnit or --pest for Pest PHP. The test will be placed in the tests folder under the same directory structure as the generated class. For example,

php artisan make:model Product --test

will create a PhpUnit test at tests/Feature/Models/ProductTest.php.

php artisan make:job Shop/ProcessSales --pest

will create a Pest test at tests/Feature/Jobs/Shop/ProcessSalesTest.php

Adding to custom/additional commands

If you want to add this functionality to a custom command, it's as easy as adding the CreatesMatchingTest trait to any command that extends GeneratorCommand.

Currently, I've added this functionality to the following commands:

• make:command
• make:job
• make:listener
• make:mail
• make:model
• make:notification
• make:controller
• make:middleware

The benefit of generating tests this way is being able to quickly create a clean, matching folder structure, which many test suites end up lacking due to inconsistencies.

Let me know if there are other commands you think should have this functionality.

As always, thank you for all your hard work.

Kind Regards,
Luke

[peterfox]

if it creates tests/Models/ProductTest.php wouldn't it make more sense to go into the unit test folder instead of the test folder?

[lukeraymonddowning]

@peterfox by default, tests generated in the unit folder don't boot the Laravel app as they extend a different testcase. In most of my model tests, I'd want to be hitting the database to make sure I've set up relationships correctly, so I'd need it to be a feature test.

Realised I'd accidentally omitted the 'feature' directory from the examples though, so I've updated 👍

[peterfox]

@lukeraymonddowning sure that makes sense. That might be the only drawback I can see to this PR is it's open to interpretation. Such as for me I probably would want a unit test for a lot of things over a feature test. Equally I'm not a fan of feature tests being structured by class namespace. Not saying it's wrong, just a personal preference. I'm wondering if there's a better syntax rather than just --test to accommodate that or not.

[haheap]

I am not a big fan of the folder structure either, but could get used to it. Another alternative could be to create the file as Feature/ProductModelTest.php, Feature/OrderListenerTest.php etc. That way it is obvious what where testing while keeping the folder structure flat.

[iaK]

I think it would make more sense to put the tests in the unit/feature folder depending on the test. Controller tests goes in the feature folder, and most else goes in the unit folder.

I agree with @lukeraymonddowning that you probably want to touch the DB when testing a model, and that by default, that scaffold does not boot the app. It is however fixable by changing the stub file.

I really hope this gets merged. I have written a package to solve this exact problem, would be awesome seeing it in core!
https://github.com/iak/make-testable