Which request expires at the exact boundary?
Catch an off-by-one error in a reminder deduplication window.
The question
Patchwell is a fictional team that builds scheduling software. This is an authored practice case. An event at time t is active only while now - t is strictly less than 60 seconds. Events at exactly 60 seconds must expire.
events.filter(event => now - event.time <= 60)
| Event time | Expected active? | |
|---|---|---|
| A | 41 | Yes |
| B | 40 | No |
| C | 39 | No |
Authored example. Values are supplied for this case.
At now = 100, an event at 90 is retained.
“Which one test best exposes the bug? What repair and follow-up checks do you propose?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Restate the interval
What would you do here? Open the move you’d make.
Test the event at 40
The strong move. It separates < from <=.
Only test the event at 90
Tempting, but it misses something. Both implementations keep that event.
See how a strong candidate says it
“The active interval is younger than 60 seconds. At now = 100, time 40 is exactly 60 seconds old and must be excluded.”
Why it works: An explicit inequality removes ambiguity.
Step 2: Make the smallest repair
What would you do here? Open the move you’d make.
Subtract an arbitrary second from now
Tempting, but it misses something. That hides the rule and introduces another error.
Change the comparator and confirm units
The strong move. It fixes the specified boundary.
See how a strong candidate says it
“Change <= 60 to < 60. For the supplied data the result should contain only A. I would confirm all values use seconds before I touch time conversion.”
Why it works: The repair addresses the proven defect without adding a new time model.
Step 3: Test both sides
What would you do here? Open the move you’d make.
Test the boundary and ask about future timestamps
The strong move. It covers the proven rule without inventing policy.
Silently discard every future timestamp
Tempting, but it misses something. The case does not authorize that behavior.
See how a strong candidate says it
“I would keep tests at ages 59, 60, and 61, plus an empty event list. I would ask how future timestamps should be handled; this packet gives no contract for clock skew.”
Why it works: It separates defined behavior from an unanswered requirement.
Step 4: Tie the test to the failure
What would you do here? Open the move you’d make.
Report only the total test count
Tempting, but it misses something. A count does not show that the boundary was tested.
Check failure before the patch and success after
The strong move. It proves that this test detects this bug.
See how a strong candidate says it
“The regression test must fail under <= and pass under <. I would describe the user impact: a reminder may be suppressed for too long at the exact cutoff.”
Why it works: A useful test proves the repair changes the relevant behavior.
The answer, in short
- Decision
- Use a strict less-than comparison.
- Because
- The stated contract excludes an event at exactly 60 seconds.
- What would change it
- If the product contract includes the endpoint, the current comparator would be correct.
Common traps
- Changing code before resolving inclusive versus exclusive time.
- Inventing a clock-skew policy.
Check your answer
- Did you name the exact endpoint?
- Did your test distinguish the two comparators?
- Did you keep time units clear?
- Did you flag the undefined future-time behavior?
Last reviewed Nov 10, 2026