Convince me to use Pest in the future

[husskade]

I've given Pest another chance, and I'm currently trying it out in another project. But I'm constantly bumping into some problems, as was the first time around (currently I'm exploring the utter uselessness of "with" for something other than trivial tests - no dynamic data, ignoring Carbon::setTestNow, unclear error messages etc.).

Is there actually something I can do in Pest, that cannot be done in clear PHPunit? And I don't mean here that it can be done slightly more easily or elegantly in Pest, but some kind of setup or expectation that cannot be done in PHPunit without writing half of the Pest codebase myself.

[fabio-ivona]

Hi, why dont' you post up here some PHPUnit tests that you find hard to convert to Pest?

[paulshryock]

Is there actually something I can do in Pest, that cannot be done in clear PHPunit?

From Pest's documentation ("Why Pest"):

Our goal is to make tests easy to read and understand, with a code syntax that closely resembles natural human language. In addition, the test reporting is well-organized, practical, and informative, with clear and concise error and stack trace displays for quick debugging.

So with Pest as an abstraction layer over PHPUnit, we have two stated goals:

1. Familiar API
2. Better reporting and debugging

---

that cannot be done in PHPunit

I don't think there's anything in Pest that cannot be done with PHPUnit.

With that said, Pest does add some of its own features (aside from the familiar API and better reporting and debugging):

Pest also offers a range of other valuable features, including:

• Built-in parallel features for faster test runs
• Beautiful documentation that's easy to navigate
• Native profiling tools to optimize slow-running tests
• Out-of-the-box Architectural Testing to test application rules
• Coverage report directly on the terminal to track code coverage
• Dozens of optional plugins, such as Watch Mode and Snapshot testing, to customize Pest to fit your needs.