-
Improvement
-
Resolution: Fixed
-
Minor
-
3.0.4, 3.1, 3.2
-
MOODLE_30_STABLE, MOODLE_31_STABLE, MOODLE_32_STABLE
-
MOODLE_33_STABLE
-
Prerequisite:
Run php admin/tool/phpunit/cli/util.php --buildcomponentconfigs1) Run these 3 commands with the patch NOT applied. Annotate times, memory and look the generated report (including all moodle codebase). Be patient or abort it after 15 minutes, as you wish, LOL. With all them you get the message "Warning: No whitelist configured for code coverage"
$ vendor/bin/phpunit -c auth/db --coverage-html /tmp/auth$ vendor/bin/phpunit -c mod/forum --coverage-html /tmp/forum$ vendor/bin/phpunit -c lib/dml --coverage-html /tmp/dml2) Run the same 3 commands with the patch APPLIED. Compare times, memory and the generated report. Way better in all them (quicker, lighter and more focussed). The warning shown in 1) is not there anymore.
3) Verify that executions without code coverage continue working:
$ vendor/bin/phpunit$ vendor/bin/phpunit -c auth/dbThat's all. Ciao
Prerequisite: Run php admin/tool/phpunit/cli/util.php --buildcomponentconfigs 1) Run these 3 commands with the patch NOT applied. Annotate times, memory and look the generated report (including all moodle codebase). Be patient or abort it after 15 minutes, as you wish, LOL. With all them you get the message "Warning: No whitelist configured for code coverage" $ vendor/bin/phpunit -c auth/db --coverage-html /tmp/auth $ vendor/bin/phpunit -c mod/forum --coverage-html /tmp/forum $ vendor/bin/phpunit -c lib/dml --coverage-html /tmp/dml 2) Run the same 3 commands with the patch APPLIED. Compare times, memory and the generated report. Way better in all them (quicker, lighter and more focussed). The warning shown in 1) is not there anymore. 3) Verify that executions without code coverage continue working: $ vendor/bin/phpunit $ vendor/bin/phpunit -c auth/db That's all. Ciao
Right now trying to get code-coverage reports for any phpunit run is slow and memory intensive, mainly because there is not any filter helping to reduce the information to be processed. Than means that, for any run, the whole moodle codebase is incorporated to the report, and every executed file has its own report, no matter it was the target or no.
In the other side, since inception we have the --buildcomponentconfigs that creates a personalized phpunit.xml file within every component in moodle, in order to facilitate partial executions like:
$ vendor/bin/phpunit -c auth/db
|
$ vendor/bin/phpunit -c mod/forum
|
$ vendor/bin/phpunit -c lib/dml
|
This issue is about add the missing <filter> element to all those personalized phpunit.xml files in order to get easy and quick code-coverage report for any component in moodle, ignoring the rest of code-base. So, basically, all these executions should be blazing-fast (compared with current behavior) and memory light:
$ vendor/bin/phpunit -c auth/db --coverage-html /tmp/auth
|
$ vendor/bin/phpunit -c mod/forum --coverage-html /tmp/forum
|
$ vendor/bin/phpunit -c lib/dml --coverage-html /tmp/dml
|
Pretty simple and really handy. Ciao
Disclaimer: This only improves component (-c) executions. Where components are moodle components and any other directory having a personalized phpunit.xml file generated. This does not improve complete executions at all.