Error running tests with php7.4 about bugsnag-php

[chelsea-youmans]

It seems that it's because of this function declaration:

bugsnag-php/src/Report.php

Line 923 in 362b93b

private function enumToString(UnitEnum $enum)

If you simply remove the UnitEnum parameter type declaration from that line, then Phake will happily mock Bugsnag\Report, even if it's type is still declared in the docblock.

[johnkiely1]

Hi @randykinne,

The enumToString method using that type isn’t called unless there is a UnitEnum instance in metadata: https://github.com/bugsnag/bugsnag-php/blob/362b93bb4b1318bb4bfe3a9e553413e6c2c1f382/src/Report.php#LL855 so its not clear why Phake would be suggesting this class doesn't exist as it should never actually be called and therefore irrelevant.

The bugsnag-php library is completely type safe and backwards compatible to php5.5. I believe this is more likely an issue with Phake incorrectly catching this as an error. Perhaps you could ask their support team for clarification on this or is there is a suggested workaround.

[chelsea-youmans]

Hi @johnkiely1!

It isn't so much an issue with being backwards compatible for our general usage of the library, but rather that Phake cannot create a mock of this class because of the strong typing done on enumToString()'s signature.

When you create a mock with Phake, Phake goes and creates mock classes for every type that's referenced in a method signature on the class. This includes private methods, in order to support this feature. So as long as the new UnitEnum type is used on a method signature (even a private one), Phake cannot create a mock for it in older PHP versions.

As I said in my comment above, the solution is to remove UnitEnum on L923. You can leave it in the docblock, but it cannot be used in a method signature in order for Phake to be able to mock it.

[johnkiely1]

Hi @chelsea-youmans,

I see what you are saying. So in essence because of how Phake mocks classes it can end up creating an implied dependency. To me this does still sound like something Phake should address as it seems like this could cause a lot of false positives across a lot of libraries. Going to close this out as theres not much we can do on it.

Either way it seems you have found a workaround.

@randykinne does this work for you?

[chelsea-youmans]

Hi @johnkiely1, I have gone ahead and opened a pull request for the fix I had suggested: #657