Should sleep() change the frozen time? about freezegun HOT 11 CLOSED

I've worked around the issue by doing this:

    @mock.patch('time.sleep')
    def test_timeout(self, mock_sleep):
        with freeze_time() as frozen_time:
            mock_sleep.side_effect = lambda seconds: frozen_time.tick(timedelta(seconds=seconds))
            ...

from freezegun.

I like the idea, but am a bit worried about backwards compatibility. Maybe a parameter to pass to the decorator.

My biggest concern is that it could cause harm to the 90% of users that wouldn't use the feature (imagine they are using some third party library that decides to call sleep()). With a parameter though, I think it would work.

from freezegun.

I'd like an option for time to generally keep ticking after freezing, so that two now() calls surrounding a long computation can get the actual difference rather than 0 seconds. I'm not using freezegun for tests though so much as re-running a computation as if it were a different day.

from freezegun.

That seems reasonable to me. I would accept a pull request with that as a default-off parameter.

from freezegun.

I would be interested in implementing a mock for sleep--we have some integration tests that I'd love to be able to run sleep during rather than routing our code around the sleep calls when under test.

Just want to check how to do this before I dive in--the right thing to do here is to create a FakeSleep class analogous to FakeStrfTime, have its call method move forward the time_to_freeze variable of the factory, and (if the parameter is supplied) patch it in everywhere the FakeStrfTime class is patched in?

from freezegun.

I don't think that should require any changes to freezegun to make work. If you do the Raw use, then patch sleep to increment the freezer.time_to_freeze.

from freezegun.

I would argue for a back-channel way to advance time. (Maybe also time.sleep should advance, but there should be a test-specific way to advance time as well.) As an example, freezegun.warp(seconds).

@spulec I started a local branch to support time.sleep/freezegun.warp, but immediately ran into the fact that FakeTime is constructed with an actual time_to_freeze rather than a reference to the possibly-nested times_to_freeze. What do you think about moving that FakeDateTime.times_to_freeze out to a thread-local stack that start/stop push and pop from?

from freezegun.

@jdunck that sounds good. I think it would actually make a lot of things easier.

from freezegun.

A freezegun.warp(seconds) would be awesome! 👍

from freezegun.

What I currently use as an intermediary (ugly) hack:

        now = datetime.now()
        # do something

        now += timedelta(seconds=0.3)
        with freeze_time(now):
             # do something 0.3 secs later

        now += timedelta(seconds=0.4)
        with freeze_time(now):
             # do something 0.4 secs later again

from freezegun.

Going to close in favor of #142

from freezegun.