Q8 of 22 · Scenarios
How would you test a date picker?
ScenariosJuniorscenariodate-pickeraccessibilityboundary-testingfunctional
Short answer
Short answer: Clarify the valid date range and locale format, then cover navigation, boundary dates (leap years, DST, timezone), keyboard accessibility, and cross-browser custom widget behavior.
Detail
Clarify first
- Are past dates, future dates, or both allowed? Is there a configurable range (e.g., not more than 90 days in the future)?
- Is the date format locale-aware, or is it fixed (DD/MM/YYYY vs MM/DD/YYYY)?
- Is there a custom widget or does it use the browser's native date input?
- Does the selected date affect other fields (e.g., end date must be after start date)?
Functional
- Clicking a date in the calendar populates the input field with the correct value
- Navigating between months and years works; correct days shown for each month
- Today's date is highlighted; selected date is visually distinguished
- Manual keyboard entry is accepted and validated
- Clearing the field via the clear button or backspace works
Negative / error handling
- Typing an invalid date (Feb 31, Jan 99, month 13) → validation error shown, form not submitted
- Clicking a disabled date (greyed-out past/future boundary) → no selection made
- Typing a date in the wrong format → clear error or auto-format correction
- Submitting the form with the date field empty (if required) → required field error
Edge & boundary
- Leap year: Feb 29 on a leap year is selectable; Feb 29 on a non-leap year is not
- Year boundaries: navigating from December to January rolls the year forward correctly
- Date range boundaries: first and last valid dates are selectable; the day before/after is disabled
- Daylight saving transition dates: 2am on the spring-forward night — no gaps in the time component if time is also selected
- Timezone: is "today" based on the server's timezone or the browser's local timezone?
Accessibility
- Calendar is fully keyboard navigable (arrow keys move between days, Enter selects)
- ARIA roles and labels on the calendar widget (role="dialog", aria-label="calendar")
- Focus management: focus moves into the calendar when it opens; returns to the input when it closes
- Selected date announced correctly by screen reader
Compatibility
- Native browser date input replaces the custom widget on some mobile browsers — test both paths; ensure the value format submitted to the server is identical
Close: automate boundary dates (leap year, range limits, Feb 28 vs 29), format validation, and the pre/post-range boundary. Keep manual for keyboard navigation and screen reader experience.
// WHAT INTERVIEWERS LOOK FOR
Leap year, daylight saving, and timezone as the boundary edge cases. Keyboard accessibility and ARIA roles. Cross-browser native vs custom widget path.
// COMMON PITFALL
Listing only 'valid date selected, invalid date rejected.' Missing leap year, year-boundary navigation, DST, and the completely different behavior of native date inputs on mobile.
// Related questions