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
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