Add spec to test import->export equivalence
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
- [-] Changelog entry
- [-] Documentation (if required)
-
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
-
Separation of EE specific content
Availability and Testing
No additional risks, but we need to ensure that it does not overly slow down the test suite.
Closes #39543 (closed)