Currently, the state-based change derivation tests in tools.vitruv.framework.views.changederivation validate the correctness of the derived changes by comparing the derived changes to the recorded ones. This is a too strong constraint as we cannot expect the change derivation to yield the exact change sequence in any case. Rather, we should validate the final state of the resource after applying the derived changes. In addition, in some test cases it might be reasonable to expect certain characteristics from the change sequence, like a correct semantic ordering (contained elements are created after their container) or the absence / presence of a certain change operation type (like element creation / deletion).
Some tests already use state validation but rely on EMF Compare to validate the state. As the change derivation strategy currently also uses EMF Compare, we should consider switching to another validation mechanic as the validation of a tool with itself can easily result in missing errors.
For further discussion, see #515.
Currently, the state-based change derivation tests in
tools.vitruv.framework.views.changederivationvalidate the correctness of the derived changes by comparing the derived changes to the recorded ones. This is a too strong constraint as we cannot expect the change derivation to yield the exact change sequence in any case. Rather, we should validate the final state of the resource after applying the derived changes. In addition, in some test cases it might be reasonable to expect certain characteristics from the change sequence, like a correct semantic ordering (contained elements are created after their container) or the absence / presence of a certain change operation type (like element creation / deletion).Some tests already use state validation but rely on EMF Compare to validate the state. As the change derivation strategy currently also uses EMF Compare, we should consider switching to another validation mechanic as the validation of a tool with itself can easily result in missing errors.
For further discussion, see #515.