[ xmlunit-Bugs-1860681 ] DifferenceEngine.compareNodeList

[SourceForge.net <no...@so...>]

Bugs item #1860681, was opened at 2007-12-29 23:17
Message generated for change (Settings changed) made by bodewig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377768&aid=1860681&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.1
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: jmeister (joerg-meister)
Assigned to: Stefan Bodewig (bodewig)
Summary: DifferenceEngine.compareNodeList

Initial Comment:
Hello,

it seems to me as if there is a bug in the non-deprecated version of the method DifferenceEngine.compareNodeList(). To illustrate what I mean, I have generated a small example for you. Let's say, we have the following test respectively control structure:


===[ testDoc ]================================

<books>
  <book>
    <title>Kabale und Liebe</title>
  </book>
  <book>
    <title>Schuld und Suehne</title>
  </book>
</books>



===[ controlDoc ]=============================

<books>
  <book>
    <title>Schuld und Suehne</title>
  </book>
</books>



Now, we want to compare these structures via XMLUnit. To do so, we generate a DetailedDiff and use a MultiLevelElementNameAndTextQualifier for a correct Node matching:


Diff diff = new Diff(controlDoc, testDoc);
diff.overrideElementQualifier(new MultiLevelElementNameAndTextQualifier(2));
DetailedDiff dd = new DetailedDiff(diff); 
Iterator i = dd.getAllDifferences().iterator();   
while (i.hasNext())
  System.err.println((Difference) i.next());


The result of the comparison are the following error messages (the structure of the messages are always "comparing <ctrl_node> to <test_node>" with their respective XPaths):

Expected number of child nodes '1' but was '2' - comparing <books...> at /books[1] to <books...> at /books[1]
Expected sequence of child nodes '0' but was '1' - comparing <book...> at /books[1]/book[1] to <book...> at /books[1]/book[2]
Expected presence of child node 'null' but was 'book' - comparing  at /books[1]/book[1] to <book...> at /books[1]/book[2]


The first and the second message are OK. XMLUnit compared the node "Schuld und Suehne" of the control structure (/books[1]/book[1]) to "Schuld und Suehne" of the test structure (/books[1]/book[2]) and recognized, that the sequence of nodes is different.
Now the problem arises: Since there are no more nodes in the control structure, but one node left in the test structure, the DifferenceEngine throws a "CHILD_NODE_NOT_FOUND" message for this node. The problem is, that the XpathNodeTracker for test and control structure are not updated in the source code, therefore they return the wrong XPath for the unmatched node "Kabale and Liebe" - it says it is "/books[1]/book[2]", but in reality it is "/books[1]/book[1]"... In this case (a node in the test structure has no counterpart in the control structure or the other way around), the XpathNodeTracker always return the XPaths to the last node matched in test respectively control structure...

I have attached a proposal of how this problem may be solved. Therefore you would have to change the DifferenceEngine as well as the XpathNodeTracker. I have marked up the lines within the source code with the key word "CODE_CHANGE", so it should be easy for you to understand what I mean. If you realize it that way, the result for the example given above would be:

Expected number of child nodes '1' but was '2' - comparing <books...> at /books[1] to <books...> at /books[1]
Expected sequence of child nodes '0' but was '1' - comparing <book...> at /books[1]/book[1] to <book...> at /books[1]/book[2]
Expected presence of child node 'null' but was 'book' - comparing  at  to <book...> at /books[1]/book[1]


Why is it that important, that you fix this bug? Well, if you want to react on the "CHILD_NODE_NOT_FOUND" event in a DifferenceListener, then you will need the exact XPath for the node that has no counterpart. At the moment, the wrong XPath is returned. Besides that, the error message in its current form is confusing...

I have used

JUnit 3.8.1
Xerces 2.8.1
XMLUnit 1.1


Hope this helps,

Joerg

----------------------------------------------------------------------

Comment By: Stefan Bodewig (bodewig)
Date: 2008-01-04 11:29

Message:
Logged In: YES 
user_id=113148
Originator: NO

Hi Jörg,

I've turned your test into a testcase and committed a disabled version of
it (stating my expectations of what the XPaths should be) to svn:
http://xmlunit.svn.sourceforge.net/viewvc/xmlunit?view=rev&revision=236

Later I'm going to review your changes and we'll see whether they also
address the reverse case.

It would help tremendously if you could provide your changes as patches
(what "svn diff" would give you in a checked out copy) instead of full
files in the future.

Thanks for the report

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377768&aid=1860681&group_id=23187