"Almost" because I found at least one that appears to be
unreachable (the very first check for null). But changing this
code is out of scope of this patch.
This also updates some of the error messages to explain the
location of the error better. It appears like the incomplete
paths are copy-paste mistakes.
I also found one duplicate test case and removed it.
Change-Id: Ic0ee9d04f5cd1060ade385ef308e70d221dd2f18
I find this good practice. It makes the tests more robust (e.g.
changes to a text don't make the test fail) and is potentially
faster, as no localization needs to be loaded.
Change-Id: I6c6342c80a40ab7260c35e7f1e3052aa4a9b9358
This test was reported as being slow (approx. 0.1s, but still).
This new implementation is 10 times faster, while still
fulfilling the requirements. While the new algorithm is more
predictable (every chunk is guaranteed to contain every
character exactly onece), it's obviously still good enough.
Neither the exact length of the generated string nor the exact
length of the gzipped string matter. PHP's random number
generator might be different – possibly generating a string
that compresses different. Newer versions of the gzip library
possibly save an extra byte. Who knows. This test shouldn't
care, as long as the gzipped string is long enough.
Compatibility with PHP 7.1 can be dropped as it is not
supported any more since MediaWiki 1.34, as far as I can tell.
Change-Id: I8d63390c9f4baa6084f932fa34068f606696cafc
Mostly unused variable initializations. Note I'm inlining some
`var` keywords in this patch. This is in line with the current
style guides. See for example the discussion in I4f198e2 (search
for "hoisted" in the comments). However, I'm not changing the
entire codebase, as this is not the goal of this patch and also
just not necessary at this point.
Change-Id: Ibd80566c44584851ee2530d6b16dd28eb3db6bfe
Two main mistakes:
* The {...foo} syntax is for a variable number of parameters.
But this is not the case here.
* Optional parameters should be marked as such via [foo].
Change-Id: I0c26ea44fab6094616443ce8fae4fd47c61fd7c4
This is covering parts of the TemplateDataHooks class. This
class does have a rather simple structure:
Either hook handlers are independent from each other. We don't
need to worry about accidental coverage then and can go with a
trivial top-level @covers tag.
Or some small helper methods are called. These are parts of
what's tested and should count as covered as well, I would
argue.
Change-Id: I6f419ae80b9ad78ff86ef2922db3178b29e244a4
assertEquals() does have weird effects, like not reporting a
method that is expected to return null but returns an empty
string, and such. While it's usually not a problem, I learned
to avoid it.
Change-Id: I4f27ed5b200278021e051f1ab4d272f48e0bf344
At the moment, when the user clicks the "Status" column to
sort by status, the statuses are ordered alphabetically,
which gives widely varying results depending on the language.
But there is an inherent order for these, even hard-coded in
the code: When a parameter is deprecated, nothing else matters.
Otherwise it's required → suggested → optional. Doesn't it
make much more sense to order the column this way? Especially
because there are never more than these 4 hard-coded values.
This is one of the (few remaining) issues mentioned on
https://de.wikipedia.org/wiki/Vorlage:TemplateData#Vorlagendokumentationsseite_verbessern_%E2%80%93_MediaWiki_ungen%C3%BCgend
This patch also makes it so that a CSS class name is always
added to all status fields, not only to the required ones.
This allows for per-wiki or per-user styling.
Change-Id: Id3f1ffafe09a3817972a4ee4bd4a3ded7be6f039
