| commit | b086645bd7714f7447ff4575684400e759de6c6e | |
| author | Eloy Lafuente (stronk7) <stronk7@moodle.org> | |
| Fri, 16 Apr 2021 22:45:55 +0000 (17 00:45 +0200) | ||
| committer | Eloy Lafuente (stronk7) <stronk7@moodle.org> | |
| Sat, 17 Apr 2021 10:32:35 +0000 (17 12:32 +0200) | ||
| tree | 7e8d006d7ba731b603b786e8876491b204381953 | treesnapshot (tar.gz zip) |
| parent | 9600becce358ff8ad22a03de4d358279e7a10ed5 | commitdiff |
MDL-71364 behat: fix randomness causes by "now" advancing
Some recent tests do set a date time element
to ##now## or tomorrow and, immediately after that
the look if, effectively, ##now## and #tomorrow#
have been set (with minutes resolution).
Problem is that, between the field is set and the field
is verified, it can happen that the time advances to
next minute (from H:M:59 to H:M+1:00) and then the
assertion fails.
To avoid this, we could have lowered the resolution to be
hours... but that doesn't solve the problem just makes it
to happen less often.
So, instead of that... we are setting the 2 now and tomorrow
cases to be "today noon" and "tomorrow noon" (12:00:00) so
we ensure they won't be ever in the risk of jumping of minute.
Some recent tests do set a date time element
to ##now## or tomorrow and, immediately after that
the look if, effectively, ##now## and #tomorrow#
have been set (with minutes resolution).
Problem is that, between the field is set and the field
is verified, it can happen that the time advances to
next minute (from H:M:59 to H:M+1:00) and then the
assertion fails.
To avoid this, we could have lowered the resolution to be
hours... but that doesn't solve the problem just makes it
to happen less often.
So, instead of that... we are setting the 2 now and tomorrow
cases to be "today noon" and "tomorrow noon" (12:00:00) so
we ensure they won't be ever in the risk of jumping of minute.
| lib/tests/behat/datetime_any.feature | diffblobblamehistory |