Single use method in both BadTitleErrorTest and ThrottledErrorTest,
merge into only place that needs it
Change-Id: I1a5c2ed2ac76ae821758d50b7d6378acb98af861
These were left behind during the initial sprint (344481f60d) for
UnitTestCase as it used a global variable. Since then, UnitTestCase
has gained support for resetting these automatically for simple
cases like this. No need to bring in IntegrationTestCase for it.
Change-Id: Id8717c1f4148510ae4a67aec7a2dc0d23679a5ac
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
This patch adds two more commonly used methods for params/rawParams to
getMockMessage and relocates the functionality to the MediaWikiTestCaseTrait.
Follows-Up: Ia94521b786
Change-Id: If9a6ccf1885ba11fbf3fb1b586006118462c1410
$wgLang is usually going to be a stub, since its semi-deprecated
so more and more code-paths don't call it. I'm not exactly sure
what checking it was supposed to accomplish. Note that
MWExceptionRenderer has very similar logic that does not check
$wgLang
Bug: T246619
Change-Id: I101a60b6fb3bc2c1abfa16fd1784caab3f75a95b
This patch fixes all PHPUnit 8 compat issues in the DBless suite, aside
from assertArraySubset.
Bug: T192167
Change-Id: Iea782386509b9e579f06d63687669e14bc437fad
This changeset resumes work on T89432 and related tickets
by porting an initial set of tests to the new unit test suite
separated out in I69b92db3e70093570e05cc0a64c7780a278b321a.
The tests were only ported if they worked immediately without
requiring any changes other than changing the test case class
to MediaWikiUnitTestCase and moving the test to the new suite.
If a test failed for any reason (even trivial misconfiguration),
it was NOT ported.
With this change, the unit tests suite now consits of a total
of 455 tests. As before, you can run these tests via the following
command:
$ composer phpunit:unit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ibb8175981092d7f41864e641cc3c118af70a5c76
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
It's annoying and pointless. Instead, have MWException write them to
standard output where we can catch them with ob_start().
Bug: T170028
Bug: T170029
Change-Id: Icd99c1c39d4a30d78c511d33948ef639e1b92455
Right now, ErrorPageError *assumes* you're never running on the cli
or the API. It's kinda a crappy superclass to use for errors unless
you're 1000% sure you'll never hit that code path. Yay assumptions!
Ideally, all of this report() crap is cleaned up and unified across
the like 1192902117 places we have it spread out, but for now just
detect the scenario and delegate back to MWException, which does the
right thing
Bug: T168337
Change-Id: Ia2f490528e128527a7a5ef1f4f5eea36ec9ee810
Skip deprecation period because it is very unlikely that anyone used this:
it does not appear anywhere on gerrit/git, no nontrivial google hits,
the documentation has been flat out wrong for 9 years and no one
noticed it, and the whole feature is fairly useless as you need to declare
it separately for every single exception class you expect.
Change-Id: I85844a238d3135d05eeba10331149624b04bafe2
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
Removed redundant set up in these classes (same as their paren
class MediaWikiLangTestCase does already).
* BlockTest
* ExportTest
* MWTimestampTest
* TitlePermissionTest
Change-Id: I28d18cb797bb249981727b02dffce4f0d8682b02
Found by running tests under a version of PHP patched to report
case mismatches as E_STRICT errors.
User classes:
* MIMEsearchPage
* MostlinkedTemplatesPage
* SpecialBookSources
* UnwatchedpagesPage
Internal classes:
* DOMXPath
* stdClass
* XMLReader
Did not change:
* testautoLoadedcamlCLASS
* testautoloadedserializedclass
Change-Id: Idc8caa82cd6adb7bab44b142af2b02e15f0a89ee
Follows-up b36d883.
By far most data providers are static (and PHPUnit expects them
to be static and calls them that way).
Most of these classes already had their data providers static
but additional commits sloppily introduced non-static ones.
* ResourceLoaderWikiModuleTest, 8968d8787f.
* TitleTest, 545f1d3a73.
Odd unused method 'dataTestIsValidMoveOperation' was introduced
in 550b878e63.
* GlobalVarConfigTest, a3e18c3670.
Change-Id: I5da99f7cd3da68c550ae507ffe1f725d31e7666f
- Removed spaces after not operator (!)
- Removed spaces inside array index
- use tab as indent instead of spaces
- Add newline at end of file
- Removed spaces after casts
Change-Id: I9ba17c4385fcb43d38998d45f89cf42952bc791b
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: Ic8aaf0a93796b97d0fa4617c1f86ff59f4b36131
ThrottledError currently returns a 503, which in turn results into
badly-written spambots occasionally flooding our 5xx logs and graphs.
There is no reason, however, for ThrottledError to return a 5xx in the
first place: it's a user-generated error (user hitting a rate limit and
being throttled), not a server error. 5xx error codes in general have
many other implications, such as frontend caches treating this as a
backend failure and potentially retrying the same request, so they are
unsuitable and undesirable for the ThrottledError exception.
RFC 6585 (April 2012, updates: 2616) has added a special 4xx code
specifically for rate-limiting, 429 Too Many Requests. As the
description of that code matches exactly what ThrottledError was meant
for, switch it to using 429 instead.
Note that there is a chance 429 might be mistreated and not showed by
older or badly-written user agents as it's fairly new and not part of
RFC 2616, the original HTTP/1.1 spec. However, the last paragraph of
section 6.1.1 of RFC 2616, specifically covers the issue of UAs &
unknown status codes: it dictates that applications MUST understand the
class of any status code and treat them as the "x00 status code of that
class" (here: 400), MUST NOT be cached, and "SHOULD present to the user
the entity returned with the response, since that entity is likely to
include human-readable information which will explain the unusual
status".
Change-Id: I46335a76096ec800ee8ce5471bacffd41d2dc4f6
- Added spaces after if/foreach/catch
- Added new line before end of file
- Added or removed spaces before/after parenthesis, comma
- Added spaces around string concat
Change-Id: I0590070f1b3542108e242730e8d9a3ba9831e94f
