Main questions and arguments against Pest as the default Laravel testing tool.

[alexmartinfr]

Nuno recently proposed a PR to make Pest the default testing tool in Laravel.

Here is a summary of the main questions and arguments against it. This should help Pest target people's needs more accurately in the future.

All points are extracted from actual quotes and edited for brevity.

Common questions:

• Will PHPUnit still work?
• Will I have to rewrite my PHPUnit tests?
• Will there be breaking changes in the future forcing me to rewrite my tests?
• Is there any large-size real-world project using Pest yet?
• What about PHPUnit compatibility in obscure edge cases?
• What problem does Pest solve that PHPUnit doesn't?
• Will Dusk, BrowserKit Testing & Orchestra also move to Pest?
• Why switch to Pest and not to the atoum framework or Codeception?
• Why does this PR remove PHPUnit from composer.json?
• Why does it rewrite the default tests with the Pest syntax?
• What about IDE integration and ease of use?
• Can the PHPStorm/Idea test runner run Pest tests?
• Can I still get XML and coverage reports for my CI environment?

Arguments against it:

• Pest is not old enough yet.
• Pest is not stable enough yet.
• The Pest ecosystem is not mature enough yet.
• Pest only offers PHPUnit features via a different syntax.
• Pest adds mental overhead to devs switching to Laravel.
• Pest forces devs experienced with PHPUnit to learn a new tool.
• Pest doesn't have enough resources & educational content.
• "Pest ****" will return less Google results than "PHPUnit ***".
• Pest is not the defacto standard tool. PHPUnit is.
• A hybrid test suite with both PHPUnit & Pest is not optimal.
• Pest as the default wouldn't be good for PHPUnit's future.
• Pest will fragment the testing community.
• The syntax is only familiar if you’ve used tools like Mocha or Jest.
• This looks like change for the sake of change.
• The name is not enticing.

Arguments in favor:

• Pest is to PHPUnit what Laravel is to Symfony.
• Pest saves time debugging tests with the improved output.
• The fluent syntax is easier to understand for newcomers and feels more natural.
• The data provider syntax is great.
• Pest has great syntax, makes it easy to write tests.

Alternatives suggestions for now:

• Offer Pest as a preset / an optional scaffolding.
• Mention/recommend Pest in the official documentation.

Conclusion

• Most of the arguments made are definitely valid. These ones shape what we'll need to work on in futur releases.
• A few others show a wrong understanding of what Pest is. I think better communication could fix that.

Please add anything I might have missed, and feel free to comment!

[nunomaduro]

Thank you for compacting those questions. Some of the stuff got addressed.

[joelmellon]

A few others show a wrong understanding of what Pest is. I think better communication could fix that.

I agree entirely. At this point I think PHPUnit is aging and is in need of a massive overhaul, hence my search for something new and my subsequent discovery of Pest. Does Pest "extend" PHPUnit or compete with, replace, and/or rewrite its functionality from scratch? And as mentioned above, can I run both? etc.

Even just a blurb clarifying a couple basic things for new (potential) users at the top of the readme, would be a great start.

I for one hate PHPUnit with its terrible documentation, deprecated features, ever changing API, and the handful of projects that attempt to add onto it, or be used along side it, eg. Mockery, Collision, Codeception, etc, etc. The PHP unit testing ecosystem is so...I don't know, ghetto is the only word that jumps to mind. Knowing how Pest fits into this space seems like an obvious thing to advertise.

TL;DR: Why should I use Pest?

[Dziamid-Harbatsevich]

Hi! Thanks for the Pest for php review. From first sight, where is the parent class? I mean, how can I drive the inheritance or any OOP in Pest? If anyone know... I am mot acquinted with it yet.

[owenvoke]

@Dziamid-Harbatsevich, the parent class for the test case? 🤔 That's covered in the documentation here. The default parent class is PHPUnit\Framework\TestCase, which can be overridden by using uses(CustomTestCase::class)->in('path'); in Pest.php or uses(CustomTestCase::class); in a specific test file. 👍🏻

[vstyler96]

I know this is closed and probably my comment is not going to be read soon, but is there any difference with execution time on multiple files? Are tests going to run parallel by default?

[GavG]

I know this is closed and probably my comment is not going to be read soon, but is there any difference with execution time on multiple files? Are tests going to run parallel by default?

As PEST is an abstraction of PHPUnit, there is an inherent, tiny performance reduction, this is typically negligible.

[chiragc2]

It's too late to make Vote for pest but as PHP developer we need to welcome such changes on eco system. (yes that will impact on development life cycle and execution delays on project, but at same time we can educate community with many resources) yesterday i have show playwright.dev i wish they could ship🚢 Pest code export on same feature. or any php-dev who wanted to stick with PHP one can build a competitive app using NativePHP

[GavG]

I have recently attempted to convert a codebase with PHPUnit tests to Pest, just to see if it were feasible, and thought it might be informative to share my experience.

Firstly, the conversion tool that we used had some shortcomings, no support for strict mode, issues with abstract classes. So, the output needed to be adjusted with seveal regexes find and replace routines.

Secondly, we were using some PHPUnit extension packages for things like XML assertions, which were not compatible with Pest.

Thirdly, the formatting of the outputted code and test names wasn't great and a pass of PHPCBF was unable to fix it without manual intervention.

In the end we gave up and left the project as is. We deemed that there would be too much work involved for not enough gain.

So, the next question we had to discuss in our team was, do we use Pest for future greenfield projects?

On the one hand it's shiney and new and learning new coding styles is great. On the other hand, all of our current projects use PHPUnit and everyone is well versed in it, introducing Pest would add some degree of context switching and additional mental overhead.

We've decided to stick to PHPUnit for the time being. As for what we think the default testing framework should be for new Laravel projects, we're not bothered as long as we can run what we like there's no problem. Yes, it'll be a wee bit more effort, but, ultimately, web frameworks are just a guide/collection of useful patterns. Testing frameworks, like any code, should never be too tightly coupled to the application framework if it can be helped so as to maintain a healthy architectural boundary. As it stands users have a choice of test framework so all is well 👍

[Sophist-UK]

I installed Jetstream (which has phpunit tests) and ran Pest and nothing passed. I was expecting existing PHPunit tests to continue working.

So I ran the official Pest migration tool - and it migrated only one of the Jetstream tests and even that one failed after conversion.

I then tried running phpunit and got an error about Pest instead.

This is IMO simply insanity.

I cannot see any reason why Pest shouldn't be implemented in a way that:

1. Allows you to continue to run phpunit on test suites that are all phpunit.
2. Allows you to run Pest on test suites that are either phpunit or Pest tests or a combination of the two.

This is IMO a MAJOR inhibitor to take-up of Pest because you cannot turn it on and refactor existing tests over time and it turns what could be an easy, gentle migration from phpunit to Pest as time permits into a major big-bang traffic-jam conversion project.

Or have I misunderstood this?

NOTE: The reason that most tests didn't migrate was because they were already Pest tests.