Tracking deprecations about tester HOT 6 OPEN

I never understood the point of it. Can you give a specific example of what problem it solves?

from tester.

Are you asking about tracking the usage of deprecated code? As a user/consumer of the 3rd party package, I would like my CI with Nette Tester to fail, if I use some deprecated API.

from tester.

I am asking about @trigger_error().

from tester.

The main pro-argument I've seen is what I've mentioned - it's side-effect free by default, i.e. the deprecation tracking is opt-in.

But that's not really a problem I want to discuss here... The bottom line is that this strategy is used by various 3rd party packages and it is quite popular. As a user/consumer of those packages and user of Nette Tester, I would like to have way how to detect those deprecations.

from tester.

And what do you mean by „detect those deprecations“? Something like a $scream from your second pull-request?

from tester.

Yes, something like that. What exactly "detect" means is one of the things I wanted to discuss.

Catching these deprecation warnings requires a custom error handler, what happens next is an open question. Should the error be simply unmuted and bubble up? Should it be only logged and reported as a soft error at the end of tester run? Should this be configurable? Should there be some kind of support for ignoring specific deprecations? Does it make sense to have various categories for deprecations from direct / indirect calls along the lines of phpunit symfony bridge?

Currently, it's not even very feasible to implement this reliably outside of Nette Tester, because Assert::error() registers own error handler, which does not pass the not handled errors up to the previously registered error handler.

from tester.