A test suite that books hotel rooms has a problem ordinary suites do not: it is
written on one date and run on every later one. Fixtures pinned to 2026-12-20
are fine until the day arrives, then they are silently in the past, and code
that filters on CURRENT_DATE starts returning nothing. The test does not fail
because the logic broke. It fails because the calendar moved.
PANTHEON has a guard for this. It reads the test files as text and rejects absolute dates:
_ABSOLUTE = re.compile(r"\b(?:datetime|date)\(\s*20\d\d\s*,")
It had been green for weeks.
Proving a green test is actually looking
I had converted two dates in test_availability_rls.py to relative offsets and
left the change uncommitted. Before committing I wanted to know the guard would
have caught them, so I put the literals back and ran it.
It stayed green.
That is the whole finding. A guard that passes when you reintroduce the exact
defect it exists to catch is not a guard. it is a green tick with no opinion.
The regex matches the constructor form, datetime(2026, 12, 20). The
fixtures I had just fixed were written the other way:
"2026-12-20"
A bare ISO string, compared against .isoformat() output on the far side of a
CURRENT_DATE filter. Identical rot, invisible to the check.
The one with ten days on the fuse
Widening the pattern to both forms surfaced five more. Four were inert. The
fifth was test_pending_hold_soft_holds_overlapping_dates, pinning a check-in
to 2026-09-10, ten days out when I found it.
Its assertion is assert overlap.startswith("ON HOLD"). The tool it calls
begins:
if ci < now().date():
return "NOT AVAILABLE, in the past"
On 11 September that test goes red, and it goes red on the soft-hold path — the code that stops two guests holding one room. The failure would have looked like a double-booking regression on a Monday morning. It would have been a calendar.
What I did not do
Nineteen absolute dates live in test_stay_bookings_rls.py, more than any
other file. They are still there, deliberately. That suite passes its reference
date in explicitly:
sb.due(as_of=date(2026, 9, 1))
Nothing consults the clock, so nothing rots. Adding them to the guard would
have produced nineteen false positives and taught the next person to add
# noqa on sight. A check that cries wolf gets disabled within a week, and
then it protects nothing at all.
The distinction the guard needs is not is this an absolute date but does anything compare it against today. That is the property worth enforcing.
The generalisation
Two things came out of this that I now apply everywhere.
A guard is not verified until you have watched it fail. Not reasoned about it failing, watched it. The date-bomb guard read as correct. It had a plausible regex, a clear name, and a passing run. Reintroducing the defect took under a minute and was the only thing that told the truth.
A check that reads source as text is testing prose, and prose has synonyms. This regex knew one spelling of a date. The same class of hole appears in any lint that greps: it constrains what you thought to write down, and stays quiet about the rest.
The fix was four lines of regex. Finding it required assuming the green tick was lying.
Commit 5fe042f in the PANTHEON repository;
the suite is 1,646 tests across 213 files.