The XML serialization of Studio features evolves with the Java classes representing the features to be serialized with XStream.
When these classes evolve, it is possible to break the followowing mechanism:
- XStream deserialization: for instance, when adding a new boolean field to the java class, if it not present in an old persisted file, deserialization will fail (it will not fail if the field is using non-primary type Boolean)
- build logics could fail: the builder logics might not take into account the fact that some fields have a null value
- client editor logics could fail: some UI editors might not take into account the fact that some fields have a null value
It is possible to handle that reusing the ModelTester logics: current XML serializations can be duplicated and kept as a reference so that they do not evolve with Java classes changes.
- add a test checking deserialization of these files
- add a test checking build of features corresponding to these files
- add a webdriver test checking that UI editors do not produce an error when displaying features corresponding to these files