Severity: Low · Area: Tests / quality · Category: test-cannot-fail
Location: services/agent/tests/test_reminder_handler.py:122
What's wrong
The test's only assertions are "status" in result and result["messages"] == [] (lines 122-123) — both are true for every dict reminder.handle() can return (ok or error), so no behavioral regression can make this test fail. The name says 'rejects_empty_body' but the handler never rejects: title/body fall back to "Reminder" (reminder.py:127-128) and delivery IS attempted. The docstring admits this. Worse, _make_notifier is not stubbed, so the test exercises a real HAPushNotifier whose send() only 'works' because awaiting a MagicMock raises TypeError which HAPushNotifier.send swallows (notifiers.py:282-286) — the observed status is an accidental "error".
How it fails
The actual empty-body guard at reminder.py:136-143 (config with body/title/name all falsy after strip, e.g. title=" ") is reachable but has zero coverage; deleting that guard or breaking the fallback chain changes behavior with every test green.
Suggested fix
Split into two real tests: one with all-whitespace title/body/name asserting status=="error" and error=="empty body", and one asserting the "Reminder" fallback with a stubbed notifier asserting send was awaited with title=""/body="Reminder".
Adversarial verification — both skeptics confirmed
Skeptic 1 (confirmed) — Confirmed. The test's only assertions ("status" in result, messages == []) hold for both return dicts handle() can produce (reminder.py:136-143 and 193-208), so it asserts nothing about the behavior its name claims. With title=""/body="", the fallback chain at reminder.py:127-128 yields "Reminder"/"Reminder" and delivery is attempted — t…
Skeptic 2 (confirmed) — Verified against reminder.py, notifiers.py, and the test file. Both return paths of handle() include "status" and "messages": [], so the test's two assertions (lines 122-123) are true for any dict the handler can return — no return-value regression can fail it. The input {"title": "", "body": ""} never hits the empty-body guard: title fa…
Filed from a multi-agent audit of 855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against 855f5cc and will drift as the code changes.
Severity: Low · Area: Tests / quality · Category:
test-cannot-failLocation:
services/agent/tests/test_reminder_handler.py:122What's wrong
The test's only assertions are
"status" in resultandresult["messages"] == [](lines 122-123) — both are true for every dict reminder.handle() can return (ok or error), so no behavioral regression can make this test fail. The name says 'rejects_empty_body' but the handler never rejects: title/body fall back to "Reminder" (reminder.py:127-128) and delivery IS attempted. The docstring admits this. Worse,_make_notifieris not stubbed, so the test exercises a real HAPushNotifier whose send() only 'works' because awaiting a MagicMock raises TypeError which HAPushNotifier.send swallows (notifiers.py:282-286) — the observed status is an accidental "error".How it fails
The actual empty-body guard at reminder.py:136-143 (config with body/title/name all falsy after strip, e.g. title=" ") is reachable but has zero coverage; deleting that guard or breaking the fallback chain changes behavior with every test green.
Suggested fix
Split into two real tests: one with all-whitespace title/body/name asserting status=="error" and error=="empty body", and one asserting the "Reminder" fallback with a stubbed notifier asserting send was awaited with title=""/body="Reminder".
Adversarial verification — both skeptics confirmed
Filed from a multi-agent audit of
855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against855f5ccand will drift as the code changes.