[18.0][FIX] account_financial_risk: Freeze time and match the module's own date reference in tests - #575
Conversation
…date reference in tests _max_risk_date_due() computes the "today" boundary with fields.Date.context_today() (timezone-aware: this env's admin user defaults to Europe/Brussels), while the tests date-stamp their records with the naive fields.Date.today(). Whenever the real wall-clock instant a test runs at falls within the user's timezone offset window around midnight UTC, the two disagree by a day, pushing a record dated "today" out of the "open" (not yet due) bucket the assertions expect it in - reproduced 2026-09-09 close to midnight UTC, and confirmed reproducible on demand by freezing at an unsafe instant (23:30 UTC) before settling on a safe one. Two changes, both needed: freeze time at a fixed, safe instant (noon UTC, clear of any realistic timezone offset crossing a day boundary) with freezegun's @freeze_time, already used the same way throughout this codebase for date-dependent OCA tests, so the test's result no longer depends on real wall-clock time at all; and use fields.Date.context_today(cls.env.user) instead of the naive fields.Date.today() for the test's own date references, so it exercises the exact same date computation _max_risk_date_due() itself uses rather than one that merely happens to agree with it under the current freeze.
OCA-git-bot
added
series:18.0
mod:account_financial_risk
carlosdauden
changed the title
|
This PR has the |
| from odoo.addons.base.tests.common import BaseCommon | ||
|
|
||
|
|
||
| @freeze_time("2024-01-15 12:00:00") |
There was a problem hiding this comment.
Setting the decorator at class level has some side effects that @victoralmau can say that he has already suffered in some cases. Please put the decorator at methods level instead (including setUpClass if needed).
There was a problem hiding this comment.
The side effect I encountered with this is that if a test was run with “post-install” and “freeze_time” was defined, the rest of the (post-install) tests that ran afterward used that date.
It seems that this test is not a “post-install” test and won't have that problem.
In any case, I don't exactly remember right now the version of Odoo in which the issue I described occurred.
There was a problem hiding this comment.
Thanks for the explanations. Let's continue this way if you say there's no problem, although maybe for consistency would be interesting to unify them.
|
/ocabot merge patch |
|
This PR looks fantastic, let's merge it! |
|
Congratulations, your PR was merged at 3709eda. Thanks a lot for contributing to OCA. ❤️ |
6 participants
_max_risk_date_due() computes the "today" boundary with fields.Date.context_today() (timezone-aware: this env's admin user defaults to Europe/Brussels), while the tests date-stamp their records with the naive fields.Date.today(). Whenever the real wall-clock instant a test runs at falls within the user's timezone offset window around midnight UTC, the two disagree by a day, pushing a record dated "today" out of the "open" (not yet due) bucket the assertions expect it in - reproduced 2026-09-09 close to midnight UTC, and confirmed reproducible on demand by freezing at an unsafe instant (23:30 UTC) before settling on a safe one.
Two changes, both needed: freeze time at a fixed, safe instant (noon UTC, clear of any realistic timezone offset crossing a day boundary) with freezegun's @freeze_time, already used the same way throughout this codebase for date-dependent OCA tests, so the test's result no longer depends on real wall-clock time at all; and use
fields.Date.context_today(cls.env.user) instead of the naive fields.Date.today() for the test's own date references, so it exercises the exact same date computation _max_risk_date_due() itself uses rather than one that merely happens to agree with it under the current freeze.
@Tecnativa
ping @sergio-teruel @carlos-lopez-tecnativa @juancarlosonate-tecnativa @CarlosRoca13