refactor(tests): Fix flaky ItemizableUpdateService test #5479
+39
−40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #4496
Description
Fix flaky ItemizableUpdateService test. The issue is caused by the use of Timecop and having order dependence on Event entries in the logic that are ordered by event_time, updated_at.
Looks like that given some specific seeds the order of entries into the DB with the exact same timestamp would then sometimes result in out-of-order (vs entry order) events being returned that would be processed in
InventoryAggregate:inventory_forin the wrong order, causing unexpected results as seen in the screenshot.Recommendation is to not freeze time unless you want the time to be consistent across the test execution, I have instead removed the global time freeze and used it as a block on specific tests to mock
Time.nowsimilarly to what was intended before.Also replaced usage of
subjectwith a method definition as subject is normally and object not a method call, but can revert this change.Type of change
How Has This Been Tested?
Screenshots
How the issue was found
--bisectto try and trim down to the least specs possible. In this case surprisingly it was all tests although manual edits and runs later proved that it could be trimmed down a bit.InventoryAggregate:inventory_forwhere events were being outputted in a different orderorder(:event_time, :updated_at)(note noidin it)It was pretty hard to find, got lucky by getting a seed that would cause a similar issue consistently.