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
Valid values for ParserCache::$mIndexPolicy are '', 'noindex', and 'index'.
The test cases use the bogus value 'policy1', which causes issues when
refactoring more strictly enforces validity checks on index policy
values.
Change-Id: I2d00ff4e3ded043d18942c8482a39fac14ec60bc
