The two hooks were moved to a PHPUnit extensions which uses hooks. The
rest was simply deleted. The reason for this change is that TestListener
was removed in PHPUnit 9, with PHPUnit hooks as replacement.
No hooks exist for startSuite/endSuite, plus we should avoid adding too
much functionality: if the output of PHPUnit isn't clear, that should be
reported upstream. Additionally, PHPUnit hooks were also deprecated in
PHPUnit 10, which means that extending PHPUnit becomes more and more
difficult. As such, the two hooks will be hard-deprecated & removed
soon.
Removing all these wfDebugLog and other function calls should also
hopefully speed up the suite.
Bug: T243600
Bug: T225730
Change-Id: I2b67cd0074aca4b0ea76696ce9f24be68f5f88f8
The TestListener interface is deprecated. This replacement has the
downside of using a public static property, but there seems to be no
other way to pass extra data to the printer (BTW: the ResultPrinter
class is internal, so it'd be even better if we could avoid subclassing
it).
Bug: T243600
Change-Id: I083146b7336ac09dfd077c8e6817553738282662
Split Maintenance::showHelp() from Maintenance::maybeHelp(), and
override it in phpunit.php. Expose PHPUnit's protected method
Command::showHelp() in our subclass and call it, so that running
"phpunit.php --help" causes the MediaWiki options to be shown, followed
by the PHPUnit options.
Change-Id: I4687d484e322a465af0492789645819cd8a7b67c
These were made final in PHPUnit8. Since there seems to be no easy way
to work around that, partially revert
Ibcaf9ca81c8dc63cce6dc6f6fb1fffee19f8804e and start using static
properties again (cfr. T192167#5550034).
Split from Ic14f5debc53e55d67146dc96279d26dfd52b4000.
Bug: T192167
Change-Id: I3fe163738662ae41eb275a0327cb33187290a70f
The initial implementation of reporting logs with test failures was
incorrect, it always reported the logs of the most recent test run.
Attach logs to the Test when a failure is reported and pull them
back out in the result printer.
Bug: T217489
Change-Id: I5aa55d6fa7a7ec03a2e71636b6b0366ea40605cb
When a unit test fails it is possible, perhaps even likely in some
cases, that some code that was run logged useful information about
how that failure came to be.
Help people out, tell them what happened!
Change-Id: I30bbc31799a65024868678d052fec9aafacc1aff
Otherwise, session tests don't work in PHP 7.2 because headers are
already sent: https://bugs.php.net/bug.php?id=75628
Bug: T206476
Change-Id: Ie88db4a61a56b756c6445d2579a2f30da22c3ee8
* Instead of rewriting $argv, add a Command subclass called
MediaWikiPHPUnitCommand which overrides the configuration using the
stub functions in Command which were provided for that purpose.
* Revert c804a0b5b9, which added redundant debug output to tests,
and instead install the MediaWikiPHPUnitTestListener listener
unconditionally. Deprecate and make non-functional the --debug-tests
option. If you don't want tests to produce debug output, you can
always turn the channel off.
* Because I added our listener to the listener array instead of making
it override the printer, it's no longer necessary to derive from
PHPUnit\TextUI\ResultPrinter. Instead we derive from BaseTestListener.
So we don't need to call the (empty) parent methods.
* Remove the --with-phpunitclass feature since it doesn't work with this
scheme.
* Instead of passing CLI args to MediaWikiTestCase via a public static
variable, inject it non-statically by overriding the TestRunner and
TestResult.
* Remove --file, which has been non-functional since my 2016 refactor.
Change-Id: Ibcaf9ca81c8dc63cce6dc6f6fb1fffee19f8804e
This also slightly refactors MediaWikiPHPUnitTestListener
so we can pass it into phpunit directly using the
--printer option
Change-Id: I6a19e3902130eeba6a0941f24a4f440b712058e5
This adds a listener to the PHPUnit test runner that will report
testing progress via wfDebugLog. This is useful for debugging
situations in which phpunit itself fails to report errors and
does not terminate normally. Having a debug log should at least
help with locating the trigger of the problem.
Change-Id: I433537a7f26197d8cff6f133e26ae5709871500f
* Cleaned up 'server' option to not fragment the pool.
Also made it actually match the documentation.
* Made it use doGetPeriodicTasks() for job recycling.
* Made it so that other job queue classes can be tested.
* Renamed "redisConf" => "redisConfig".
* Tweaked comments about the "random" order option.
Change-Id: I7823d90010e6bc9d581435c3be92830c5ba68480
Fix almost all occurences of the following sniffs:
Generic.CodeAnalysis.UselessOverridingMethod.Found
Generic.Formatting.NoSpaceAfterCast.SpaceFound
Generic.Functions.FunctionCallArgumentSpacing.SpaceBeforeComma
Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLine
Generic.PHP.LowerCaseConstant.Found
PSR2.Classes.PropertyDeclaration.ScopeMissing
PSR2.Files.EndFileNewline.TooMany
PSR2.Methods.MethodDeclaration.StaticBeforeVisibility
Change-Id: I96aacef5bafe5a2bca659744fba1380999cfc37d
* merge() will use CAS if supported or use locking otherwise
* The lock()/unlock() methods now have a default implementation
* added unit tests for merge
Change-Id: Ic27088488f8532f149cb4b36e156516f22880134
This introduces --wiki as a dummy paramter to the PHPUnit job, so it no
longer complains and errors our. The parameter is already picked up
correctly be Maintenance.php.
I have a wiki family setup with a Wikibase repo and client using the
same install base, and the same LanguageSettings.php. Different
databases etc are triggered based on the request URI or, for maintenance
scripts, by the --wiki paramters.
I can run maintenance scripts etc against the client setup using --wiki
client. But how do I run unit tests against the client setup? If I try:
$ phpunit.php --wiki client
unrecognized option --wiki
$
That's because after Maintenances.inc (correctly) processes the command
line parameters, phpunit also tries to process them - and complains,
because it doesn't know --wiki.
This change introduces --wiki as a dummy parameter to phpunit to work
around this. With this patch applied, I can run unit tests against my
client setup using phpunit.php --wiki client as expected.
Change-Id: I6cf319cdbdf55a541c986838d370aa324994ae78
MediaWikiTestCase now calls wfProfileIn/wfProfileOut for each call
to a test function. This makes it easy to track down slow tests.
Change-Id: I5ff2fea957c082f41da37936fe44948ad006f573
Previously, no profiling data was recorded from unit test runs.
That made it impossible to a) use unit tests for selective profiling
of individual functions, and b) made it impossibel to profile
the tests themselves.
This change fixes this problem by calling wfLogProfilingData()
after the test runner has finished.
Thaks to Hashar for some ideas, especially the fix in GlobalFunctions.
Change-Id: Iaa295115f3c4eb3b529388dcd953fe8932448b3e
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
* CloneDatabase - already droping tables in internal function, removed duplicate action
* DatabaseOracle - stopped ignoring "temporary" parameter
* added two parameters to phpunit (use-normal-tables & reuse-db), default actions stay the same
* with reuse-db oracle phpunit test run on oracle down to 1m 20s ;)
Adds tests/phpunit to the include_path to let PHPUnit find out our files.
Also add to change the suite.xml paths from './path' to 'path' so
stream_resolve_path() correctly find out the suite by using include_path
suite.xml now comes with colors=true. Under Windows, we override the
setting by forging a --no-colors. One can still force color usage
under windows by using --colors.
-No need to specify a new function for each argument, use PHP5 magic to automatically set it
-Create (g|s)etCliArg() functions
-Implement some features from the old parser tests
lack of fuzz testing and other parser test options, and the DB creation is still a little flaky.
A MediaWikiPHPUnitCommand class had to be created to allow for custom CLI parameters.
