Rain test fails randomly about asciimatics

[peterbrittain]

Yeah - seeding the RNG is a good idea. I'll push something to master.

[peterbrittain]

Interesting... I completely agree that future stability is important, but will struggle to test this as I don't have an openSUSE build env.

First thing to check here is how reproducible this failure is... These tests are for deliberately randomized effects and so sometimes hit failures due to the random seed. If so, I can tweak the warm up for this test to let it run a little before checking output.

Does this always fail like this, or was it a one off?

[bmwiedemann]

Hmm. I cannot reproduce it anymore, so it probably really is more of a random failure, independent of the date.
Maybe use a fixed random seed then or let the test retry on failure?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[peterbrittain]

Naughty stalebot! I'll fix this...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bmwiedemann]

I added random.seed(42) in various places but still get random failures in TestParticles.test_drop_screen and test_rain, unless I do it there:

--- asciimatics-1.14.0.orig/asciimatics/effects.py
+++ asciimatics-1.14.0/asciimatics/effects.py
@@ -12,7 +12,7 @@ from builtins import object
 from builtins import range
 from future.utils import with_metaclass
 from abc import ABCMeta, abstractmethod, abstractproperty
-from random import randint, random, choice
+from random import randint, random, choice, seed
 from math import sin, cos, pi
 from asciimatics.paths import DynamicPath
 from asciimatics.screen import Screen
@@ -54,6 +54,7 @@ class Effect(with_metaclass(ABCMeta, obj
         :param stop_frame: Stop index for the effect.
         :param delete_count: Number of frames before this effect is deleted.
         """
+        seed(42)
         self._screen = screen
         self._start_frame = start_frame
         self._stop_frame = stop_frame

[peterbrittain]

Interesting... Given that the random numbers are deterministic once the seed is set, the only reason it wouldn't follow the same path is because of some systemic difference. Are you running the test with multiple threads, or something like that?

[bmwiedemann]

My guess is that randomness is used before tests run random.seed(42) e.g. in

asciimatics/asciimatics/effects.py

Line 509 in 31b3fe5

self._maybe_reseed(True)

Which is why it became deterministic when adding it early in asciimatics/effects.py

[peterbrittain]

That doesn't quite make sense. Those should only get invoked once the class is constructed (i.e. in the test). I'd also like to avoid seeding inside the real code...

Did you try using the setUp() method of the unittest class to set the seed? Something like this:

class TestParticles(unittest.TestCase):
    def setUp(self):
        seed(42)