How do I suppress console errors when testing a class that catches an error in a dependency with phpunit9.5 and php8.0 - phpunit

Question

I have a class that takes in a dependency. One of the things the class does is catch errors thrown by that dependency (does something useful to log this, and goes on to return a return the rest of the code finds useful.)
In PHPUnit, I can mock up the dependency and test as follows:
$stubqueryrunner = $this->createStub(QueryRunner::class);
$stubqueryrunner->method('getArray')->will($this->throwException(new \Error));
$inner = new myClass("mark", $stubqueryrunner);
$this->assertEquals(["what" => "", "why" => ""], $inner->getReasons());
The class I'm testing catches any error raised in its dependencies (and returns some default values) for the getReasons method.
My code passes my tests (ie - the Method I'm testing has indeed caught the error and substituted the default values.)
However, the act of raising the error writes many lines of stack trace to the output of PHPUnit.
I can't use the # operator at the point I call it, because I'm in PHP8, where the stfu operator is deprecated for errors.
I can't use
/**
* #expectedError PHPUnit\Framework\Error
*/
... because that's not in PHPUnit 9.
So how do I actually suppress all the stack trace stuff from appearing in the PHPUnit console?
Update: Adding
$this->expectException(\Error::class); just creates an additional assertion which then immediately fails precisely because the class I'm testing has successfully caught it.
The code I'm testing never actually produces errors. The only thing that's producing an error is the Stub I've written in the Unit test when it runs throwException
Adding error_reporting(0); in the test doesn't help.

Answer 1

I can't use the # operator at the point I call it, because I'm in PHP8, where the stfu operator is deprecated for errors.
The # operator may be deprecated, but what it does, is not.
Suppress the errors by settings or setting blank the error-handler for the lines of code you used the # operator previously and you should get it to work (functions that come to mind: error_reporting(), set_error_handler()).
This should then already suppress the error and henceforth even if the Phpunit run configuration is "sharp" and would mark the test as a failed on error (or at least warns, this is what you normally want in testing) as the error has been suppressed before Phpunits test-runner could be noticed by it (the phpunit error handler is set blank when you set your own handler, and active again after you unset it), there is no additional handing of it any longer by Phpunit.
So how do I actually suppress all the stack trace stuff from appearing in the PHPUnit console?
The previous stacktrace may not be fully gone after the change if some internal handling is adding it. One extension that does this I know about is xdebug and the stacktrace might then be caused by runtime configuration.
Take care you're using the right settings in testing or at least don't fear if you still see a stacktrace and can't explain it to yourself.
For Xdebug it's the develop mode in xdebug, remove it and the stack-traces done by xdebug to aid in development are gone.
You should get it to work on the level of the test. This would be the first milestone. Lets assume already being there and add some more context:
You now have two tests:
The original test (that is not sufficient for you under PHP 8, maybe even fails).
The regression (new) test where you take care of the error handling.
I'd say, the (original) test shows, that the code under test itself is not forward compatible with PHP 8. So what has been patched into the (regression) test to get it working should ideally become part of the implementation.
The previous test then should run again, regardless of which version. So you would have the old test, and the new test to test for the regression.
I'd consider this a bit of a luxury problem. Not because its superfluous, but by the description of the error handling, this is not straight forward code so it needs extras in development, testing and maintenance and should have actual a decent staff to take care of these.
See just in testing, its hard. Even the simple things like what the # operator is and while already seen as the cause of change, it's overly puzzling - why?
It might be because error handling is hard and testing for error handling maybe even harder.
Q/A Reference:
How to simulate and properly write test with error_get_last() function in phpunit