PHP 8.1 changes the order of protected properties in the output
of serialize(). Previously they were at the end of the
serialized stream, now they are at the beginning.
Given that serialization formats have multiple equivalent encodings,
and there is no guarantee that they might not arbitrary change between
versions in backwards compatible ways, I think we should not do
byte for byte comparisons. Instead we should deserialize both
and compare the resulting objects for equality. This should test
what we want to know (That we can read serialized structures) well
also being safe against compatible format changes.
This fixes a number of failing ParserOutputTest::testSerialization
on php 8.1.
Bug: T313663
Change-Id: Ic7a08b436d65ab7492f343fa02281e245834aaea
It's just a nice, lesser known convenience function. Exists since
PHP 5.5.
The changes to SerializationTestTrait ended being a little different.
Original I tried to use array_column() as well. But it drops the
array keys, which is relevant here.
We found that calling the two methods getTestInstances(AndAssertions)
multiple times is quite expensive and should be avoided. I changed
the code slightly so it's much less likely this is done unintentionally.
Change-Id: Ifaba3c370871a7c97b4d81ec21ff6ec134433fc0
The initial object comparison using `==` compares all the property values
using `==` as well. This causes (for example) the string "1" to compare
as equal to the number `1`, the empty string `""` to compare as equal
to the number `0` and other surprising things.
It appears that this comparison was done at an attempt at performance
optimization, but that has little place in a test suite. Use the full
recursive strict comparison instead.
This requires updating one ParserCache test case which was apparently
created incorrectly (or not properly updated) and relied on the
previous behavior (numbers comparing as equal to strings) to pass.
Change-Id: Ife0e9ccc7be0f4933975bb326203693bc15a9658
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
Methods called in @dataProvider are not counted in code coverage,
making an impression we are not covering serialization code.
Move calling the serializer/deserializer into some of the tests
to fix coverage reporting.
Change-Id: I014bdee94b7297f6d298a3fea91482674c666fe3
CacheTime::mUsedOptions and ParserOutput::mAccessedOptions
do exactly the same thing and has to be merged into a single property.
This patch adds forward-compatibility and needs to be deployed
at least one train before the patch which actually merges the properties.
Change-Id: Ic9d71a443994e2545ebf2a826b9155c82961cb88
2020-11-10 07:09:41 -07:00
Renamed from tests/phpunit/includes/parser/SerializationTestTrait.php (Browse further)
