Run PHPUnit rather than Pest

Question

I have a project with a mixture of tests wrtten in Pest and regular PHPUnit Test Classes. There is a lot missing from Pest for package developers and its just simpler to use the PHPunit for areas where Pest can't help. Pest is great and I can use it 90% of the time but the odd thing is missing. When I run php vendor/bin/phpunit I get:

Pest\Exceptions\InvalidPestCommand 

Please run [./vendor/bin/pest] instead.

I can't see any options to bypass Pest here according to the docs for CLI.

Has anyone had any success in running these side by side.

Note: I am aware that Pest will run PHPUnit TestCases but a lot of annotations provided by PHPUnit simply can't be used with Pest. e.g. @runTestsInSeparateProcesses

Answer 1

This seems to be a rather big rabbit hole. I'm digging, because I'd like to run phpunit tests using sail with options, which is falling over... All IT jobs everywhere talk about TDD, but

<rant>
I'm still yet to find a good framework which understands the required tooling for both Unit and Feature tests.
</rant>

My findings for anyone following at home. Running sail phpunit is pointing me to pest. (same as OP posted)

In my case I don't want to run pest (I'm comfortable with PHPUnit and don't have the time to learn the differences right now.) so I bit the bullet and used Pest.

I thought surely the sail test command is simply a wrapper to pest right? Nope. Turns out there is an entire package that adds the test output manipulation (https://github.com/nunomaduro/collision)

Nothing against this package, I'm familiar with PHPUnits convention and don't mind a change.

It seems that Laravel is pretty set on moving from PHPUnit directly to Pest.

Sorry I don't really have a better answer

Please correct me if I'm wrong, but laravel's philosophy on unit testing is basically, write a DB Feature test instead. That's at least my impression from all the Laracasts, Forum responses and the 1st party docs on Testing (https://laravel.com/docs/11.x/testing)

[Just a guy trying to actually do TDD (or at least write tests during, rather than after, development)]