test: drop ZeroconfServiceTypes.find() timeouts from 500ms to 200ms on loopback#1710
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1710 +/- ##
=======================================
Coverage 99.76% 99.76%
=======================================
Files 33 33
Lines 3426 3426
Branches 471 471
=======================================
Hits 3418 3418
Misses 5 5
Partials 3 3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
2 tasks
…n loopback `ZeroconfServiceTypes.find()` is just `time.sleep(timeout)` (it doesn't short-circuit on the first matching response), so the timeout becomes a lower bound on the test runtime. Each of these tests calls `find()` twice, paying 1s of pure sleep on top of ~200ms of setup. On loopback the registrar's response lands within a few ms, so 200ms is ~50× headroom. `test_async_zeroconf_service_types` also slept 200ms after `async_register_service` to let the last announce broadcast land — that one already has the `quick_timing` fixture (which patches _REGISTER_TIME=10ms), so 50ms is plenty. Speedups: - test_integration_with_listener: 1.28s → 0.67s - test_integration_with_subtype_and_listener: 1.27s → 0.66s - test_integration_with_listener_v6_records: 1.27s → 0.67s - test_integration_with_listener_ipv6 (same pattern, not in #1707 list): 0.67s - test_async_zeroconf_service_types: 1.54s → 0.77s
The 0.2s `ZeroconfServiceTypes.find()` / `async_find()` timeout used by the four loopback service-types tests was a bare float literal at ten call sites. Hoist it to a `LOOPBACK_FIND_TIMEOUT` constant in `tests/__init__.py` so the rationale lives in one place.
cfd311b to
6424140
Compare
4 tasks
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Part of #1707 (slow tests sweep). Bucket C of a 3-PR series (follows #1708, #1709).
ZeroconfServiceTypes.find()is implemented as a baretime.sleep(timeout)— it doesn't short-circuit on the first matching response — so the timeout argument becomes a lower bound on test runtime. The integration-with-listener tests each callfind()twice and pay 1.0s of pure sleep on top of ~200ms of registration setup. On loopback the registrar's response lands within a few ms, so 200ms is ~50× headroom.test_async_zeroconf_service_typesalso slept 200ms afterasync_register_serviceto let the final announce broadcast land. That test already has thequick_timingfixture (which patches_REGISTER_TIME=10ms), so 50ms is plenty.Speedups:
test_integration_with_listenertest_integration_with_subtype_and_listenertest_integration_with_listener_v6_recordstest_integration_with_listener_ipv6(same pattern, not in #1707)test_async_zeroconf_service_typesStable across 3 sequential runs. No production change.
The cleaner long-term fix is making
find()event-driven (return as soon as expected types arrive) — left for a follow-up since that's an API-shape change.Test plan
tests/suite passes (337 passed, 3 IPv6 skips)