The idea is for all entry points to use the MediaWikiEntryPoint
base class, to improve consistency and testability.
Bug: T354216
Change-Id: I3678afe32c7c1a313d2dcb1808286c25ecd167eb
Mocks a ContainerInterface to support a specific list of services,
with has() and get() working correctly, and uses that for a real
ObjectFactory object.
Change-Id: Ie49b5a34e0f449cc4b9f6b31d6cc1bc943d04b43
This is a modified version of Ie282bc5b5f5df0bbd6a40c8362ba73fcbbf36c2e
which was reverted in 5c7cca8776.
Bug: T321969
Change-Id: I566d54a473aa51c4cdaada21a49d63c0624aab93
This reverts commit d32c260ed0.
Reason for revert: Timo has reservations, I'll submit an updated version later.
Change-Id: I71d4d61a879fda4dccfc105127446cfedde75a7b
PHPUnit tests will fail to run in the IDE if they access the service
container.
Note that the structure test will not include routes registered by
extensions when run without the phpunit wrapper: data providers are
executed before config is loaded, so extensions do not have a chance to
register.
Change-Id: If9d408456686b408062204bec4b41c95f60ab775
With PHPUnit 9, tests without @covers tags are considered risky and emit
warnings. Not having @covers is bad practice anyway, so use
@coversNothing instead to make the intention clear, and re-enable the
phpcs rule.
Also rewrite an assertion in ResourcesTest that was bothering me.
Bug: T243600
Change-Id: I6dd683f93b6b2faed5f107be2ca7860602277fbc
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
These are not only 100% identical to the actual code, but also:
* It's error-prone. Some are already wrong.
* These test…() functions are not meant to be called from
anywhere. What is the target audience for this documentation?
* There is a @dataProvider. What such @param tags actually do is
document the provider, but in an odd place. Just looking at
the provider should give the same information.
* The MediaWiki CodeSniffer allows to skip @param when there is
a @dataProvider, for the reasone listed.
Change-Id: I0f6f42f9a15776df944a0da48a50f9d5a2fb6349
Creates an OPTIONS handler that handles any OPTIONS requests that are
not already handled by a handler. CORS has no mechanism to ensure the
user is authenticated, so the Router will reject cross-origin requests
from anon users.
This change allows authenticated users to make cross-origin
requests if they authenticate with OAuth or if
$wgRestAllowCrossOriginCookieAuth is enabled.
Bug: T232176
Bug: T262712
Change-Id: I128b4bdbec4f6bea35142153c951fd7b79617106
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 tests validity of parameter definitions for the MW REST API, like
ApiStructureTest does for the Action API.
Bug: T243437
Change-Id: Iac9ca951d00573be6efe00cc07478c3581c84588
