Commit 3566c13f authored by Vincent Pelletier's avatar Vincent Pelletier

erp5_core_test: Make testWorkflowHistoryList.TestDedup stable.

The precise number of entries in a bucket depend on an estimation of the
size of a pickle. The pickled data contains DateTime objects, making an
equality test brittle:
- DateTime's timezones are stored as strings (ex: 'GMT') whose length
  depend on Zope's timezone, which is variable
- DateTime's time is stored as a floating-point value represented as a
  string whose length depends on the number of units and decimals are
  necessary to represent its value, both being variable (one based on when
  the test was run, the other based on clock precision and exact test
  execution timing)
Instead, restore the originally-considered-acceptable boundary (24) and
verify that the generated value is greater or equal to it.
If 24 is considered too small to be acceptable, then it is a decision
independent from the present change.
parent 99c67eb9
...@@ -220,5 +220,10 @@ class TestDedup(ERP5TypeTestCase): ...@@ -220,5 +220,10 @@ class TestDedup(ERP5TypeTestCase):
whl._p_deactivate() whl._p_deactivate()
finally: finally:
Workflow.dedupStrings = orig_dedupStrings Workflow.dedupStrings = orig_dedupStrings
self.assertEqual(deduped, [35]) # A single deduplication should have happened, as the loop exits on bucket
self.assertEqual(len(list(whl)), 36) # split.
new_obj_length, = deduped # pylint: disable=unbalanced-tuple-unpacking
# The exact boundary does not matter much, but it should be greater than
# some arbitrary value considered satisfying.
self.assertGreaterEqual(new_obj_length, 24)
self.assertEqual(len(list(whl)), new_obj_length + 1)
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment