The private method DOMNodeComparator::nodeToText can receive a $canonicalize flag to avoid re-loading a node.
This function is only called twice in assertEquals, and the class is final, so no descendants could override this behavior.
In DOMNodeComparator::assertEquals, nodeToText is called with an hardcoded true argument, rather than making use of the $canonicalize parameter that could be passed to it.
Moreover, \SebastianBergmann\Comparator\DOMNodeComparatorTest::testAssertEqualsSucceeds only tests the method with the default false value for the parameter.
Is there a practical reason for this? I tried searching in other issues and in the git history for the assertEquals method, but I found nothing useful.
As per a possible solution, I think it would be rather straightforward to change this current code in DOMNodeComparator::assertEquals
A new test case or a modification for the old one would be needed.
I could open a pull request if this is deemed the right solution and there is a need for it; I am not sure if this is correct behavior for a design choice, though.
The private method
DOMNodeComparator::nodeToText
can receive a$canonicalize
flag to avoid re-loading a node. This function is only called twice inassertEquals
, and the class is final, so no descendants could override this behavior.In
DOMNodeComparator::assertEquals
,nodeToText
is called with an hardcodedtrue
argument, rather than making use of the$canonicalize
parameter that could be passed to it.Moreover,
\SebastianBergmann\Comparator\DOMNodeComparatorTest::testAssertEqualsSucceeds
only tests the method with the defaultfalse
value for the parameter.Is there a practical reason for this? I tried searching in other issues and in the git history for the
assertEquals
method, but I found nothing useful.As per a possible solution, I think it would be rather straightforward to change this current code in
DOMNodeComparator::assertEquals
with
A new test case or a modification for the old one would be needed.
I could open a pull request if this is deemed the right solution and there is a need for it; I am not sure if this is correct behavior for a design choice, though.