Comparing nodes with multiple occurrance

[Quin]

Hi,

I have used XMLUnit to compare 2 documents, where some nodes may appear in multiple times as follow:

<Test>
    <LineItem>
        <ID>1</ID>
        <Info>your</Info>
    </LineItem>
    <LineItem>
        <ID>2</ID>
        <Info>your</Info>
    </LineItem>
    <Remarks>
            <Code>A</Code>
            <Info>XXXX</Info>
    </Remarks>
    <Remarks>
            <Code>V</Code>
            <Info>yyyy</Info>
    </Remarks>
</Test>

I have used the MultiLevelElementNameAndTextQualifier provided in the src and set Level to 2

The diff works fine if the test document has either a LineItem deleted or Remarks deleted, which means that it will return correctly DifferenceConstants.CHILD_NODE_NOT_FOUND_ID for the node being deleted.

However, problem occur when add/delete are performed on both.

For example, if I add a Line Item 3 and remove Remarks A, it will return DifferenceConstants.TEXT_VALUE_ID saying that the value of /Test/Remarks/Code has been changed to /Test/LineItem/ID, which is not expected.

Any suggestion on how can I get DifferenceConstants.CHILD_NODE_NOT_FOUND_ID for both new line item and deleted remarks?

Thanks in advance

Queenie

[Stefan Bodewig]

MultiLevelElementNameAndTextQualifier has never really been more than a prrof of concept implementation, maybe it simply is not good enough in your case.

You could give the qualifier from feature request 1878549 a try which is supposed to do better
https://sourceforge.net/tracker/index.php?func=detail&aid=1878549&group_id=23187&atid=377771

[Quin]

Thanks for your reply.

I have tried with the qualifier that you provided and the results are still the same.

I have implemented my own qualifier and fail also.

I have tested with the qualifier, and found that it will always return false for the newly added Line Item 3.

Is it suppose that if the qualifier return false for a testnode and control node, they won't be compare? But if it is so, why it will compare the Line Item 3 with Remarks A? Is that I misunderstand some of the concept?

Queenie

[Quin]

Since there will be doubt on using MultiLevelElementNameAndTextQualifier as it is not well tested, neither for the one in example, the one provided from feature request 1878549, and the one I develop on my own, I now do another experiement to locate where the problem is.

This time I use a much simple xml and use ElementNameAndTextQualifier

<doc>
    <id>123</id>
    <remarks>a</remarks>
    <remarks>b</remarks>
    <remarks>c</remarks>
    <remarks>d</remarks>
    <others>1</others>
    <others>2</others>
    <others>3</others>
</doc>

Here are the test results (action is done on the instance above in each round, i.e. they are not accumulated):

1. Delete remarks d --> CHILD_NODE_NOT_FOUND_ID return  --> OK

2. Delete others 1 --> CHILD_NODE_NOT_FOUND_ID return  --> OK

3. Add remarks e --> CHILD_NODE_NOT_FOUND_ID return  --> OK

4. Add others 4 --> CHILD_NODE_NOT_FOUND_ID return  --> OK

5. Delete remarks d and others 2 --> CHILD_NODE_NOT_FOUND_ID return for both nodes  --> OK

6. Add remarks e and delete others 1 --> TEXT_VALUE_ID return saying that 1 has been changed to e --> fail since we expected CHILD_NODE_NOT_FOUND_ID to be returned for both newly added <remarks> e and <deleted> others 1

From the above test, I wonder if the unexpected resutls in test no 6 is due to bug within the
ElementNameAndTextQualifier or maybe the diff engine.

[Stefan Bodewig]

svn revision 350 contains a unit test I derived from your use case, there are actually two differences, the first one is a "element tag name" difference, the second one is the text difference you describe (which is only visible if using a ComparisionControler that proceeds after the first non-recoverable difference).

What you see is an instance of bug 2758280 https://sourceforge.net/tracker/?func=detail&aid=2758280&group_id=23187&atid=377768 - XMLUnit first determines it doesn't have any test node that could be matched against the others-1 node, in that case it will match it against the first unmatched test-node which is the remarks-e node.  Not what one would expect but XMLUnit's behavior since a long time and thus unfixable without either yet another option or breaking backwards compatibility.