These tests require some exploration. The changes here add the ability to have a programatically configured whitelist and exclusion list added to the phpunit.xml, and the per-module phpunit.xml. Notes In order to run code coverage testing you need to use either `xdebug` or `phpdbg -qqr`. Both have their issues. xdebug xdebug is slow. Not just slow, but painfully slow. It will be about 10x slower than a normal phpunit run. Composer actually warns you if you have xdebug enabled it's so bad To use xdebug, you either need to enable it in your php.ini, or when running: /usr/local/bin/php -dzend_extension=/usr/local/opt/php@7.1/pecl/20151012/xdebug.so' ./vendor/bin/phpunit phpdbq phpdbg has a file handle leak ( https://bugs.php.net/bug.php?id=76801 - please vote for that issue). It's much faster, but it doesn't close the file handles when running and you soon hit maxopenfiles on your system To use phpdbg, you can run phpunit as follows: phpdbg -qqr ./vendor/bin/phpunit Running phpunit with coverage phpunit --coverage-html coverage --testsuite core_privacy_testsuite Areas to test specifying whitelist and exclusion list files in a new tests/coverage.php file checking that the generated phpunit.xml is correct checking that the generated component config phpunit.xml is correct (passing --buildcomponentconfigs to init) checking that running phpunit with a config generated via admin/tool/phpunit/cli/util.php --buildcomponentconfigs gives the same result as the main /phpunit.xml