[Wikitech-l] New `composer phpunit:entrypoint` command (phpunit.php deprecated)

TL;DR: The tests/phpunit/phpunit.php script is deprecated. Use `composer phpunit:entrypoint` instead. Thus far there have been three ways to run PHPUnit tests in MediaWiki: 1. Via simple composer command: `composer phpunit` / `vendor/bin/phpunit` (only for non-DB tests) 2. Via composer entrypoint: `composer phpunit:entrypoint` 3. Via custom PHP script: `php tests/phpunit/phpunit.php` The third method is now deprecated [1]. The `composer phpunit:entrypoint` command, previously pointing to the phpunit.php script, now uses `vendor/bin/phpunit`, specifying a config file that can be used with integration and database tests. Where you would previously use phpunit.php, you should now use `composer phpunit:entrypoint`. The rationale behind this change is to make it easier for developers to run PHPUnit tests, without having to determine what entry point they should use for a given test. The previous setup also made it more difficult to configure IDEs, because you had to switch between the available entry points to make sure that tests were run with the expected config. After this change, the only difference between `composer phpunit` and `composer phpunit:entrypoint` is the config file they use (phpunit.xml.dist and tests/phpunit/suite.xml, respectively). Note that we are also planning to phase out the latter; you can follow the conversation in [2]. When that happens, we will truly have a single entry point for all PHPUnit tests! The switch from phpunit.php to composer comes with a small but potentially significant difference: LocalSettings.php is no longer loaded in the global scope. This should work transparently to you. If one of your settings appear to have no effect, please report this on Phabricator [1]. The main scenario where these issues may arise is if your configuration variable is read early during MediaWiki setup, for instance in an extension function [3]. You can temporarily workaround this by making the config variable explicitly global in the place where it's being set, with `global $wgMyGlobal;`. Huge thanks to Timo, James F., Kosta, Antoine, Umherirrender, and everyone who helped with this long-overdue change. ---- [1] - https://phabricator.wikimedia.org/T90875 [2] - https://phabricator.wikimedia.org/T227900 [3] - https://www.mediawiki.org/wiki/Manual:$wgExtensionFunctions -- https://meta.wikimedia.org/wiki/User:Daimona_Eaytoy "Daimona" is not my real name -- he/him