This patch introduces a namespace declaration for the
MediaWiki\Json to FormatJson and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I5e1311e4eb7a878a7db319b725ae262f40671c32
Why:
* Modules that extend ApiQueryBase are loaded using the ApiQuery
module. This defines an override to the ApiBase::isWriteMode
method that loads the modules.
* Using the mModule when $isError is true could lead to the
exception that was thrown in ::executeAction being thrown again.
* Therefore, ApiMain::sendCacheHeaders should only call the
ApiBase::isWriteMode method if the request did not fail
with an error that caused $isError to be true.
* Without this fix, ApiUsageExceptions appear in logstash as
exceptions, as described in T363133.
What:
* Only interact with $this->mModule if the $isError argument
is false. If $isError is true, assume that ::isWriteMode
would return true. Assuming this will also avoid error
responses being marked as fresh for any amount of time, as
the error may be temporary.
* Add a test that verifies that the method does not throw if
ApiBase::isWriteMode throws an ApiUsageException.
Bug: T363133
Change-Id: I41d869c257878b8a94d6c40332e2028405de8729
ConvertibleTimestamp::setFakeTime does not return a ScopedCallback,
which would need a local variable, it returns the old value.
The reset is part of MediaWikiTestCaseTrait.
Change-Id: Ic479ec810f3f75cbdd393f2d91afb7a311d798a0
Error messages are not guaranteed to be stable, and these tests
prevent us from improving them.
Error codes are supposed to be stable, so we should be asserting
that they do not change (especially since many of them are
dynamically generated by the dodgy code in ApiMessageTrait).
Introduce helpers assertApiErrorCode() and expectApiErrorCode()
to be used instead of the usual PHPUnit assertions/expectations
for this case.
Change-Id: I752f82f29bf5f9405ea117ebf9e5cf70335464ad
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
To follow Message. This is approved as part of RFC T166010.
Also namespace it but doing it properly with PSR-4 would require
namespacing every class under language/ and that will take some time.
Bug: T321882
Change-Id: I195cf4c67bd51410556c2dd1e33cc9c1033d5d18
There is a common and reasonable need for longer lines in tests.
The nudge for shorter lines doesn't seem valuable here. The natural
breaks will likely still fall in 80-100 given the enforced practice
for non-test code, e.g. whether through habit, or 80-100 column markers
in text editors, or the finite width of diff and code review
interfaces.
Change-Id: I879479e13551789a67624ce66f0946d2f185e6ee
This is just a start, and only tests common situations. It's also
best-effort, since this code path is hard to follow (partly due to the
OutputPage usage).
Change-Id: I59e228982c5a5aff387698c0cce2b0ec5da4c566
With this patch deprecation warnings will be emitted
if $wgUser is accessed or written into. The only pattern
of usage still allowed is
$oldUser = $wgUser;
$wgUser = $newUser;
// Do something
$wgUser = $oldUser;
Once there is no deprecation warnings, we know that nothing
legitimately depends on $wgUser being set, so we can safely
remove the code that's still allowed as well.
Bug: T267861
Change-Id: Ia1c42b3a32acd0e2bb9b0e93f1dc3c82640dcb22
See full rationale at I59068cfed10aabf6c6002f9e9312a6ef6e7e9441.
Using IDatabase for now instead of DBConnRef for better BC.
Change-Id: Ie75aaf46ba91779e8706b10efeefa9580857f489
This is a demo, a lot of tests could be rewritten as a followup
to pass proper Authority when executing tests instead of writing
globals. Much cleaner imho.
An improvement idea is to allow overriding 'default permissions'
when creating a mock Authority.
Change-Id: I38570024e0d5a67a8e1c52f7456c458090ec2b6e
It is not entirely meaningless. It might be an indicator that
the number of calls to a method is intentionally unlimited.
This is similar to e.g. an @inheritDoc PHPDoc comment that
marks a method as being "intentionally undocumented".
However, what's the meaning of being "intentionally
unconstrained"? Let's just not have any constraint then.
I feel all these ->expects( $this->any() ) bloat the test
code so much that it's never worth it.
Change-Id: I9925e7706bd03e1666f6eb0b284cb42b0dd3be23
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
My personal best practice is to not document @params when there
is a @dataProvider. I mean, these test…() functions are not
meant to be called from anywhere. They do not really need
documentation. @param tags don't do much but duplicate what the
@dataProvider does. This is error-prone, as demonstrated by the
examples in this patch.
This patch also removes @throws tags from tests. A test…() can
never throw an exception. Otherwise the test would fail.
Most of these are found by the not yet released I10559d8.
Change-Id: I3782bca43f875687cd2be972144a7ab6b298454e
If I try to run ApiMainTest with GlobalPreferences enabled, it takes
forever (or at least some number of minutes) to run. This is because
when @depends is used to transfer data from one test to another via
the return value, PHPUnit runs Enumerator::enumerate() on the data. When
it contains a reference to the active TestCase, PHPUnit ends up
iterating through its internal data structures, which takes a long time.
My conclusion is that @depends with a return value should be considered
harmful. Stop doing it in ApiMainTest. Stop recommending it in
SampleTest.
Change-Id: I63e94f2886a4ee4b3fd0ea6b19cd2fb67ba912de
