Skip to content

Add spec to test import->export equivalence

Matthias Käppler requested to merge 39543-import-export-end2end-tests into master

What does this MR do?

To verify that changes to import/export logic do not change semantics in undesired ways, we would like to introduce tests which verify that given a previously exported project JSON, an import -> export cycle yields the initial JSON back, i.e. that this function is "isomorphic" (up to a certain degree).

This test is only concerned with the logic behind saving and restoring project trees, hence it tests against ProjectTreeSaver and ProjectTreeRestorer rather than higher level entities that also perform tasks such as managing the git repo and deflating archives.

The implementation is relatively complex; there is a lot more setup related code than there is actual test code. This is because we cannot just test two project hashes for equality, because:

  • we know that row IDs will change during import
  • there are some timestamps that are known to change

To that end I tried to get to an implementation where I can test as much as possible using the eq matcher (Ruby's Hash.== performs a deep-equals, so it does all the heavy lifting for us), and only fall back to custom matchers where I could see no other way out. I did this by:

  • normalizing both trees first by "neutralizing" IDs, i.e. give them all the same value (therefore two sub-relations will pass equality checks if all other fields match)
  • account for unordered list comparisons deep down the hash by using Set instead
  • for certain keys known to carry problematic data, provide "fallback matchers" that apply slighly weakened checks (by excluding timestamps or merely checking for presence of them) (We decided to remove this because the added complexity didn't seem worth it.)

I found a number of project relations that were not comparable for a number of reasons. We decided to break the investigation and/or special handling of these out into a follow-up issue.

TODO:

  • make spec pass for light JSON
  • make spec pass for complex JSON
  • create follow-up issue to investigate open problems

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

No additional risks, but we need to ensure that it does not overly slow down the test suite.

Closes #39543 (closed)

Edited by 🤖 GitLab Bot 🤖

Merge request reports