Skip to content

test: stop AccountTest failing when the second ticks mid-test - #896

Merged
blaipr merged 1 commit into
mainfrom
test/a-stamped-timestamp-does-not-fail-when-the-second-ticks
Aug 30, 2026
Merged

test: stop AccountTest failing when the second ticks mid-test#896
blaipr merged 1 commit into
mainfrom
test/a-stamped-timestamp-does-not-fail-when-the-second-ticks

Conversation

@blaipr

@blaipr blaipr commented Aug 30, 2026

Copy link
Copy Markdown
Member

AccountUseCases::create() and ::updatePassword() stamp passDate with time(). Five
expectations in AccountTest built theirs by calling the same factory, a moment before the
production code called it — so whenever the second ticked between the two, the two models differed
by exactly one and the test failed:

-    'passDate' => 1788098773
+    'passDate' => 1788098774

It is a real failure with nothing wrong in the code, it lands in whichever pull request happens to
be open, and it cannot be reproduced on demand — which is what made it read as a mystery rather
than a bug. It failed the 8.5 unit job on #895 while 8.4 passed on the same commit.

The change

anAccountStampedNow() compares everything else exactly and takes only passDate from the actual
model, after checking it is a timestamp from the last few seconds. A factory that stopped stamping
it, or stamped something else, still fails.

Shown both ways

With sleep(1) injected before the repository write, to make the race happen every time:

old expectations new matcher
sleep(1) before the write 5 failures 89 tests OK
service mutated to pass a different DTO 5 failures 5 failures

The second row is what keeps the matcher honest: it is tolerant of the timestamp and of nothing
else. Mutating the factory itself proves nothing here and was discarded — the test builds its
expectation with that factory, so a change to it moves both sides equally.

`AccountUseCases::create()` and `::updatePassword()` stamp `passDate` with `time()`, and
five expectations in AccountTest built theirs by calling the same factory — so the test
called time() a moment before the production code did. Whenever the second ticked between
the two, the models differed by one and the test failed: a real CI failure, in whichever
pull request happened to be open, that could not be reproduced on demand.

`anAccountStampedNow()` compares everything else exactly and takes only `passDate` from
the actual model, after checking it is a timestamp from the last few seconds — so a
factory that stopped stamping it, or stamped something else, still fails.

Shown both ways with a `sleep(1)` injected before the write: the old expectations fail
all five, the new ones pass all five, and a service mutated to pass a different DTO still
fails them.
@blaipr
blaipr merged commit aa8d53f into main Aug 30, 2026
8 checks passed
@blaipr
blaipr deleted the test/a-stamped-timestamp-does-not-fail-when-the-second-ticks branch August 30, 2026 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant