QuantEcon / QuantEcon.py / 28772176408

94%

push

github

TEST: De-flake timing tests with lower-bound assertions (#846)

* TEST: De-flake timing tests with lower-bound assertions

test_timing.py asserted that wall-clock time.sleep() durations stayed
*under* an upper bound (assert_allclose with atol/rtol). That is
inherently flaky on shared CI runners: time.sleep(t) only guarantees the
process is suspended for at least t, and a descheduled runner can make
the measured time arbitrarily larger. test_timeit_lambda_function (the
tightest case, expecting ~0.05s) failed three times recently on slow
macOS/ubuntu runners.

Replace the ~14 upper-bound checks with a lower-bound assertion
(assert_at_least): the meaningful invariant is that the timing utilities
do not under-report elapsed time; scheduler overshoot is no longer a
failure. Relationship checks (min <= avg <= max, average_time >=
average_of_best) are unchanged.

See the CI flakiness discussion in #845.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* TEST: Address Copilot review — clearer assert_at_least message

Include the computed lower bound and the factor in the failure message,
with floats formatted to 4 dp, so a future CI trip is easy to interpret.
Diagnostics only; no behaviour change.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* TEST: Restore unit-invariance guard in timing tests

The lower-bound conversion was over-applied to test_timer_units and
test_timeit_different_units. Those tests exist to verify Timer.elapsed
stays in seconds regardless of the display unit; a pure lower bound would
pass a unit-leak regression (elapsed stored in ms/µs is ~1000x/1e6x too
large), defeating their purpose.

Add assert_in_seconds: a bounded check (expected*0.9 <= measured <
expected*100) whose generous ceiling always trips on a unit leak but
never on scheduler overshoot (a few x at most). Point the two unit tests
at it; the generic timing tests keep the lower-bound-only assert_at_least.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic... (continued)

24 of 24 new or added lines in 1 file covered. (100.0%)

8024 of 8623 relevant lines covered (93.05%)

2.79 hits per line