What Is a Boundary Test for a Schedule Date Picker?
From the earlier reference collection. Read the current software blog.
Test the first and last supported service dates, adjacent dates, and the picker’s visible restrictions.
Identify the supported range
A schedule date picker often depends on the date span represented by a feed or service calendar. A boundary test should use a small fixture with a known first date and last date, rather than whatever happens to be current in a live dataset. This makes the expected available range stable.
Assert that the first supported date and last supported date can be selected if the application treats both endpoints as inclusive. If the range contract differs, state that rule directly in the fixture and expected results.
Probe just outside each edge
Test the day immediately before the first date and the day immediately after the last date. They should be unavailable if the picker is restricted to the feed range. These adjacent cases catch inclusive-versus-exclusive mistakes that testing only distant dates can miss.
Check both the control's behavior and the underlying selection logic. A disabled calendar cell is useful feedback, but a user may still enter a date manually or invoke a URL directly. The schedule lookup should enforce the same range policy rather than relying only on presentation.
Account for service calendars
A feed-wide date span does not necessarily mean service runs every day inside it. If the picker is meant to show only dates with active service, add fixtures for weekdays, weekends, and date exceptions. If it simply allows any date within the feed period, keep that policy distinct from whether a particular trip operates.
When service days extend past midnight, the selected service date can differ from the calendar date of a late arrival. Test the picker against the service date concept used by the schedule, not a derived timestamp that may cross midnight.
Make boundary failures legible
Keep the fixture dates near each other and label the expected first and last values. On failure, report the selected date and supported range. Include a year boundary if the date logic has special formatting or arithmetic around year changes, but keep it separate from the basic inclusive-edge test.
The result is a focused contract: users can select the dates the schedule supports, cannot accidentally request dates beyond that range, and see a consistent answer from both the calendar control and the schedule query.