This streamlines the code of the helper method a bit, mostly by
avoiding duplication.
What actually happens is the exact same as before, with one
exception: When a test case doesn't have an expected "output",
the default (mostly empty) output does not run through the
roundtrip test. While doing this is not wrong, it doesn't tell
us anything about the specific test case.
Change-Id: I4a3d8a22c3dd6a9c5c3766195e5aef3cf37a6441
"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
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
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
