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.