test: apply review feedback on shutdown-loop race and fixture docs

bluetoothbot · bluetoothbot · commit a30eb88c9bb9 · 2026-05-20T17:39:49.000Z
diff --git a/src/zeroconf/_core.py b/src/zeroconf/_core.py
@@ -106,9 +106,9 @@
 
 # RFC 6762 §8.1 thundering-herd avoidance: wait a random
 # 0-250ms before the first probe so simultaneously-started
-# responders don't collide. The repo enforces a 150ms floor
-# to keep the existing test deadlines comfortable; tests on
-# loopback can patch this down via the `quick_timing` fixture.
+# responders don't collide. We default to 150-250ms to
+# preserve existing timing assumptions; tests on loopback
+# may patch this lower via the `quick_timing` fixture.
 _PROBE_RANDOM_DELAY_INTERVAL = (150, 250)  # ms
 
 
diff --git a/tests/conftest.py b/tests/conftest.py
@@ -88,8 +88,10 @@ def quick_timing() -> Generator[None]:
     probing, §5.2 for the initial-query delay). Tests on 127.0.0.1
     do not need them and pay 1-2s per register/unregister cycle,
     150-250ms per probe, and 20-120ms per ServiceBrowser startup
-    without this fixture. Opt in by adding `quick_timing` to a
-    test's argument list.
+    without this fixture. Opt in either by adding `quick_timing`
+    to a test's argument list or via
+    `@pytest.mark.usefixtures("quick_timing")` on the test or
+    its class.
     """
     with (
         patch.object(_core, "_CHECK_TIME", 10),
@@ -108,9 +110,11 @@ def quick_request_timing() -> Generator[None]:
     The 200ms `_LISTENER_TIME` and 20-120ms random jitter (RFC 6762
     §5.2) help spread queries from multiple clients on real networks.
     On loopback they're pure overhead — get_service_info-style tests
-    wait ~250ms before the first query even fires. Opt in by adding
-    `quick_request_timing` to a test's argument list, then drop the
-    test's own timeouts (which had to accommodate that delay).
+    wait ~250ms before the first query even fires. Opt in either by
+    adding `quick_request_timing` to a test's argument list or via
+    `@pytest.mark.usefixtures("quick_request_timing")` on the test
+    or its class, then drop the test's own timeouts (which had to
+    accommodate that delay).
     """
     with (
         patch.object(service_info, "_LISTENER_TIME", 10),
diff --git a/tests/utils/test_asyncio.py b/tests/utils/test_asyncio.py
@@ -86,19 +86,19 @@ async def _still_running():
         await asyncio.sleep(5)
 
     def _run_coro() -> None:
-        runcoro_thread_ready.set()
         assert loop is not None
+        future = asyncio.run_coroutine_threadsafe(_still_running(), loop)
+        runcoro_thread_ready.set()
         with contextlib.suppress(concurrent.futures.TimeoutError):
-            asyncio.run_coroutine_threadsafe(_still_running(), loop).result(0.1)
+            future.result(0.1)
 
     runcoro_thread = threading.Thread(target=_run_coro, daemon=True)
     runcoro_thread.start()
     runcoro_thread_ready.wait()
 
-    time.sleep(0.05)
     assert loop is not None
     # Patch _TASK_AWAIT_TIMEOUT so the inner `asyncio.wait` returns
-    # immediately instead of blocking the full 1s on the deliberately
+    # within 50ms instead of blocking the full 1s on the deliberately
     # never-completing _still_running() task.
     with patch.object(aioutils, "_TASK_AWAIT_TIMEOUT", 0.05):
         aioutils.shutdown_loop(loop)
