Are there examples of getting pretty output from #phpunit for custom assertions?
Projects like #Pest prove you can do a lot with phpunit’s output. I’m hoping it doesn’t take that much work to hook into correctly displaying information when an assertion fails, though.
So, two questions:
If I write a custom assertion, can I be creative with how failures display?
Can I hook into the built-in assertions and conditionally tweak their display?
This is fun. Upgrading a library to #PHPUnit 10, it works fine but Xdebug isn't detected (for code coverage). php -i confirms xdebug is set to "debug,coverage", but I get a message that it must be set, or an env var provided. Providing the env var works fine, but the xdebug setting is not.
was debugging a flaky #phpunit test with executionOrder="defects" configured. it took me quite a while to figure out that the code under test was dependent on a constant and that constant was set in only one test case (which sometimes ran before the others which would break them)..
replaced the constant with something else that can be properly mocked and all is good. phew.
Is there a way to disable or hide the #PHPUnit deprecations? I have 265 of them for data providers that aren’t static, and I can’t easily switch to static data providers, since many of the data providers call instance methods (i.e., $this). So, it’s going to take me a long time to upgrade my tests so that I can upgrade to PHPUnit 10.
#PHPUnit 9 says to stop using assertObjectHasAttribute() in favor of assertObjectHasProperty(). But the latter doesn't exist in PHPUnit 9, only in PHPUnit 10.
Am I missing something obvious? Because that's not how deprecation warnings are supposed to work... #PHP
I have only recently learned of the "before" attribute in @phpunit. It seems appealing. What I don't get is... why would I ever use setUp() when I can instead use a before method? It seems like the easier, more portable solution in ever case except when I actively want to bypass a parent class's setUp().
Yesterday I added some tooling to auto-generate code coverage info about our new (2-week old) Laravel codebase. (#PHPUnit makes this easy.) It revealed 2 things:
The first thing goes to YAGNI is hard:
We already had lots of classes that had lots of empty, placeholder methods. Many of them for things we will never need. I deleted them. We can artisan make them again if we ever need them.
Testing an external api using PHPUnit (dev.to)
Nowadays, many applications need to connect to external resources to perform some operations such as...