I'm currently working on an internal plugin for moodle, and have discovered that running the PHPunit tests results in errors due to the use of debugging() calls.

I've tracked down https://tracker.moodle.org/browse/MDL-44339 which infers that any debugging() statement is an error, and as such the Unit tests fail.

It appears that the reset_debugging() function in /lib/phpunit/classes/util.php resets the debugging level to DEBUG_DEVELOPER.

I'm just wondering if this is a little too aggressive?

Currently in the plugin that I'm developing I'm using the DEBUG_DEVELOPER flag to output useful messages that provide information on the process that is being performed, to allow me to see if there is any issue happening or the data is being unexpectedly modified. All of this may be useful information in the future for tracking down any future issues, so hence the DEBUG_DEVELOPER. In normal operation this is of no interest.

So this leaves me with a resulting action to do at the end of the development process to remove all of the debugging() calls, which then should I need to find out if the internals are playing funny buggers I would then have to re-add.

This is then complicated by the fact that our release processes prohibit me modifying the code running on the live system, hence why the debugging level can be turned up and down as required to investigate any issues.

On this basis I'd challenge the notion that debugging is unexpected, and that a debugging message (certainly at DEBUG_DEVELOPER) can be always asserted as being an "error".

(I do know that I can use the assertDebuggingCalled(null, DEBUG_DEVELOPER) to check that i *did* output developer level messages but then this also seem to discard *all* debugging messages.