Menu
▾
▴
[ xmlunit-Bugs-3062518 ] DifferenceEngine error
|
From: SourceForge.net <no...@so...> - 2010-09-10 06:28:32
|
Bugs item #3062518, was opened at 2010-09-09 11:47 Message generated for change (Comment added) made by david-krzystek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377768&aid=3062518&group_id=23187 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Java 1.3 Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: David Krzystek (david-krzystek) Assigned to: Nobody/Anonymous (nobody) Summary: DifferenceEngine error Initial Comment: Hi guys, I guess I spotted an incorrect difference reporting for example desbribed below. Control document ---------------------------------------------- <Fruits> <Apple size="11" color="green"/> <Apple size="15" color="green"/> <Banana size="10"/> </Fruits> Test document ---------------------------------------------- <Fruits> <Apple size="11" color="green"/> <Banana size="11"/> </Fruits> Removing one Apple and changing Banana's attribute size in the test document, comparator reports these differences: Expected number of child nodes '3' but was '2' - comparing <Fruits...> at /Fruits[1] to <Fruits...> at /Fruits[1] Expected element tag name 'Apple' but was 'Banana' - comparing <Apple...> at /Fruits[1]/Apple[2] to <Banana...> at /Fruits[1]/Banana[1] Expected number of element attributes '2' but was '1' - comparing <Apple...> at /Fruits[1]/Apple[2] to <Banana...> at /Fruits[1]/Banana[1] Expected attribute name 'color' but was 'null' - comparing <Apple...> at /Fruits[1]/Apple[2] to <Banana...> at /Fruits[1]/Banana[1] Expected attribute value '15' but was '11' - comparing <Apple size="15"...> at /Fruits[1]/Apple[2]/@size to <Banana size="11"...> at /Fruits[1]/Banana[1]/@size Expected presence of child node 'Banana' but was 'null' - comparing <Banana...> at /Fruits[1]/Banana[1] to at null This is actually incorrect according to me. I would expect to see: Expected number of child nodes '3' but was '2' - comparing <Fruits...> at /Fruits[1] to <Fruits...> at /Fruits[1] Expected presence of child node 'Apple' but was 'null' - comparing <Apple...> at /Fruits[1]/Apple[2] to at null Expected attribute value '10' but was '11' - comparing <Banana size="10"...> at /Fruits[1]/Banana[1]/@size to <Banana size="11"...> at /Fruits[1]/Banana[1]/@size I went through the DifferenceEngine code and I could see, that the method allows the comparison of apples and bananas protected void compareNodeList(final List controlChildren, final List testChildren, final int numNodes, final DifferenceListener listener, final ElementQualifier elementQualifier) throws DifferenceFoundException The part of the code which compares unmatched test nodes with the control nodes that did not match too. ... for (int i=0; i < numNodes; ++i) { Node nextControl = (Node) controlChildren.get(i); Node nextTest = (Node) matchingNodes.get(nextControl); Integer testIndex = (Integer) matchingNodeIndexes.get(nextControl); if (nextTest == null && XMLUnit.getCompareUnmatched() && !unmatchedTestNodes.isEmpty()) { nextTest = (Node) unmatchedTestNodes.get(0); testIndex = new Integer(testChildren.indexOf(nextTest)); unmatchedTestNodes.remove(0); } ... } ... I would suggest to compare nodes of the same name. It could look like the snippet below: ... for (int i=0; i < numNodes; ++i) { Node nextControl = (Node) controlChildren.get(i); Node nextTest = (Node) matchingNodes.get(nextControl); Integer testIndex = (Integer) matchingNodeIndexes.get(nextControl); if (nextTest == null && XMLUnit.getCompareUnmatched() && !unmatchedTestNodes.isEmpty()) { nextTest = (Node) unmatchedTestNodes.get(0); // check that we are not comparing apples with bananas if (nextControl.getLocalName().equals(nextTest.getLocalName())) { testIndex = new Integer(testChildren.indexOf(nextTest)); unmatchedTestNodes.remove(0); } else { nextTest = null; } } ... } ... Anyway, thank you for your great job. David ---------------------------------------------------------------------- Comment By: David Krzystek (david-krzystek) Date: 2010-09-10 08:28 Message: I understand, that the ElementNameQualifier will make the comparison correct, nevertheless it will inhibit the correct comparison of the documents which might have nodes in a swapped order. See the example: CONTROL <Fruits> <Apple size="11" color="green"/>" <Apple size="13" color="green"/>" <Apple size="15" color="green"/>" <Banana size="10"/>" </Fruits> TEST <Fruits> <Apple size="13" color="green"/> <Banana size="11"/> <Apple size="11" color="green"/> </Fruits> TEST document is missing one apple and babana changed. Besides that, two remaining apples are swapped. Disabling the comparison of unmatched nodes and using ElementNameQualifier class, I got these differences: Expected number of child nodes '4' but was '3' - comparing <Fruits...> at /Fruits[1] to <Fruits...> at /Fruits[1] Expected attribute value '11' but was '13' - comparing <Apple size="11"...> at /Fruits[1]/Apple[1]/@size to <Apple size="13"...> at /Fruits[1]/Apple[1]/@size Expected attribute value '13' but was '11' - comparing <Apple size="13"...> at /Fruits[1]/Apple[2]/@size to <Apple size="11"...> at /Fruits[1]/Apple[2]/@size Expected presence of child node 'Apple' but was 'null' - comparing <Apple...> at /Fruits[1]/Apple[3] to at null Expected attribute value '10' but was '11' - comparing <Banana size="10"...> at /Fruits[1]/Banana[1]/@size to <Banana size="11"...> at /Fruits[1]/Banana[1]/@size It is apparent, it is a consequence of using ElementNameQualifier which relies on the the same sequence numbers, so the swapped order is not handled well. ---------------------------------------------------------------------- Comment By: Stefan Bodewig (bodewig) Date: 2010-09-09 17:01 Message: I've taken your example and turned it into a unit test with svn revision 459 (will port it to trunk which contains a completely revamped codebase soon). The test pases. http://xmlunit.svn.sourceforge.net/viewvc/xmlunit?view=revision&revision=459 You get Expected 3 child nodes was 2 Didn't find Apple[2] Attribute values differ for Banana[1] Child order for Banana elements is different - third child vs second) Of course you'd get different results if the ElementQualifier is anything but ElementNameQuaifier ---------------------------------------------------------------------- Comment By: David Krzystek (david-krzystek) Date: 2010-09-09 16:27 Message: The example was tested against XMLUnit1.3. I also tried to use the new feature you mentioned, but it still did not do what I would expect. Running the same example with XMLUnit.setCompareUnmatched (false) returns: Expected number of child nodes '3' but was '2'... Expected presence of child node 'Apple' but was 'null' ... Expected presence of child node 'Banana' but was 'null' ... Expected presence of childl mode 'null' but was 'Banana' ... I understand that the unmatched control and test nodes are printed, but I would rather expect to see, that one Apple is missing and Banana got a difference which seems to me more correct. Therefore I did not take advantage of disabling comparison of unmatched nodes. ---------------------------------------------------------------------- Comment By: Stefan Bodewig (bodewig) Date: 2010-09-09 16:12 Message: re-opening comments and changing category based on an email by David. ---------------------------------------------------------------------- Comment By: Stefan Bodewig (bodewig) Date: 2010-09-09 12:21 Message: duplicate of issue 2758280 ---------------------------------------------------------------------- Comment By: Stefan Bodewig (bodewig) Date: 2010-09-09 12:18 Message: This is addressed in XMLUnit 1.3. You should get the expected behavior if you set XMLUnit's compareUnmateched to false. See http://xmlunit.sourceforge.net/userguide/html/apas03.html#New%20Features%201.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377768&aid=3062518&group_id=23187 |
