Comparing nodes with multiple occurrance

Help
Quin
2008-02-28
2013-03-03
  • Quin

    Quin - 2008-02-28

    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

      Stefan Bodewig - 2008-02-28

      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

      Quin - 2008-02-29

      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

      Quin - 2008-03-05

      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

        Stefan Bodewig - 2009-06-19

        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.

         

Log in to post a comment.