Edge Cases: Same-Day and Contiguous Ranges

Learning Objectives

By the end of this lesson you will be able to:

• Explain the semantics of a same-day range (start == end) in both half-open and closed interval systems
• Identify zero-duration booking scenarios and test them appropriately
• Define "contiguous ranges" and explain the gap vs adjacency distinction
• Design test cases that distinguish adjacency from overlap
• Explain how adjacency bugs manifest in booking and scheduling systems

Same-Day Ranges: Start Equals End

When a user enters a start date equal to the end date, the behavior depends on the interval convention:

Half-open [start, end): the range [June 5, June 5) is empty — it contains no calendar days. This is mathematically consistent but may confuse users. A booking system using half-open intervals that accepts start == end is effectively accepting a zero-duration reservation, which is likely a bug unless the domain explicitly allows it (e.g., a same-day event).

Closed [start, end]: the range [June 5, June 5] contains exactly one day — June 5. This is the expected behavior for a system where "June 5 to June 5" means a single-day booking (e.g., a conference room reserved for one day, a car rental picked up and returned the same day).

The system documentation must clarify which semantics apply. QA must test the start == end case explicitly and verify both the acceptance/rejection decision and the calculated duration.

Zero-Duration Bookings

A zero-duration booking (where start and end produce no span) can arise in several ways:

1. The user enters start == end in a half-open system
2. A time-based booking where start time == end time
3. A calculation error (e.g., expiry set to creation date)

Zero-duration scenarios are worth testing because they expose:

• Whether the system validates duration before storage
• Whether price calculation handles zero gracefully (result should be 0, not undefined or negative)
• Whether date-range queries return the booking correctly (half-open queries exclude it; closed queries include it for single-day ranges)

Test cases:

• Submit a booking with start == end and observe whether it is accepted
• If accepted, check the calculated duration/price
• Query overlapping bookings to verify whether this booking is included in the results

Contiguous Ranges

Two ranges are contiguous when the end of one exactly equals the start of the next, with no gap and no overlap. In half-open semantics:

• Booking A: June 1 to June 5 (exclusive)
• Booking B: June 5 to June 10 (exclusive)

A and B are contiguous. Together they cover June 1–9 with no gap. June 5 belongs only to B.

In closed semantics:

• Booking A: June 1 to June 4 (inclusive)
• Booking B: June 5 to June 9 (inclusive)

Here the gap between A and B is deliberate — June 5 is the first day of B. If closed-interval logic tried to place B at June 4 (A's last day), it would overlap.

Gap vs Adjacency Bugs

Gap bug: the system requires a gap between bookings when none is needed. Example: a shift scheduling system that rejects back-to-back shifts because the overlap check incorrectly includes the touching endpoint.

Adjacency bug: the system treats adjacent bookings as overlapping and rejects valid consecutive reservations. This appears as a false conflict error.

The diagnostic test: place booking A from June 1–5, then attempt booking B from June 5–10. In a half-open system, B should be accepted. If the system rejects it with a "date conflict" error, it has an adjacency bug in its overlap detection.

Practical Test Matrix for Booking Systems

TC03 is the most diagnostic — it distinguishes half-open from closed and reveals adjacency bugs.

Summary

Same-day and contiguous range edge cases are among the most likely to produce inconsistencies between what users expect, what the UI shows, and what the backend stores. Testing start == end explicitly and submitting contiguous bookings back-to-back are essential steps for validating a booking system's date range logic. The single most important test is submitting booking B that starts exactly when booking A ends, then verifying whether the system accepts or rejects it — and whether that behavior matches the documented interval convention.