Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datetime and Time packages do not have the same behavior when being frozen #535

Open
folkvir opened this issue Mar 4, 2024 · 4 comments
Labels

Comments

@folkvir
Copy link

folkvir commented Mar 4, 2024

Hello!
A few days ago a bug occured and we discover that the time were not frozen correctly in our tests. We reported the issue in pytest-freezer (pytest-dev/pytest-freezer#14) but after deeper investigations it seems that the function _should_use_real_time reports that we should use realtime when it should'nt.
When using the 2 additional ignore elements freezegun.configure("_pytest.runner", "_pytest.terminal") (which are added to mitigate the bug on the pytest --durations option) time functions return real time in teardown fixtures while datetime functions return correct mocked time. @wimglenn tracked this here pytest-dev/pytest-freezer#14 (comment)
More precisely; the guilty ignore option is _pytest.runner. I see 3 possibilities (maybe more?):

  • Fix the _should_use_real_time; don't know if it is the right solution
  • Or try to deeply identity which element in the _pytest.runner package we need to ignore; to work with the current code without breaking the --durations option.
  • Use a plain Fake object for the time package; just like the datetime package
@bblommers
Copy link
Collaborator

Hi @folkvir! I created a standalone test case in #537 - if I'm understanding the problem correctly, that demonstrates the fact that there is indeed a bug here.

I think the appropriate fix is to extend all FakeDatetime methods to use should_use_real_time, but I don't have a lot of time to look into this - so PR's are welcome.

@bblommers bblommers added the bug label Mar 17, 2024
@folkvir
Copy link
Author

folkvir commented Mar 18, 2024

I'll try to look into it and create a pull request as soon as possible but I don't have a lot of time to spend outside my family and job. So if someone has more free time then go!

folkvir added a commit to folkvir/freezegun that referenced this issue Mar 18, 2024
@folkvir
Copy link
Author

folkvir commented Mar 18, 2024

@bblommers Ok after investigations I found calling print(_should_use_real_time()) in the beginning of FakeDatetime.now return "False" because the module name returned by: frame.f_globals.get('__name__') is never listed in ignore_lists[-1]. The ignore_list[-1] is ('tests.another_module', 'nose.plugins', 'six.moves', 'django.utils.six.moves', 'google.gax', 'threading', 'multiprocessing', 'queue', 'selenium', '_pytest.terminal.', '_pytest.runner.', 'gi', 'prompt_toolkit') but the module_name(s) are just:

freezegun.api
tests.test_configure
_pytest.python
pluggy._callers
pluggy._manager

Increasing the call_stack_inspection_limit does not change anything.
So even if we patch FakeDateTime.now with a usage of _should_use_real_time then we won't get the real_time because the function always return false!

@folkvir
Copy link
Author

folkvir commented Mar 26, 2024

Update: I think I found the core of the bug; but it may be an artefact of the test setup because we locally import the another_module module. The bug should be reproductible if you comment my changes in freezegun.api.
Changes: master...folkvir:freezegun:bug/ignore-fakedatetime-bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants