Test cases for a date picker
Updated 2026-11-13 · 6 min read
Thirty date-only booking cases with explicit inclusive limits and a blocked date. Separates native picker presentation from stored values and custom-calendar interaction.
How to answer in an interview
Ask whether the field is a calendar date or an instant, which timezone defines today and whether limits are inclusive. Clarify typed input, disabled dates and range selection before naming cases. A booking date should not change merely because the same record is viewed in another timezone.
Scope and test data
Assume a required booking range using calendar dates, inclusive limits from 2028-02-01 to 2028-03-31, and a blocked date of 2028-02-15. End date may equal start date, but a range must not cross the blocked date. These are example rules, not defaults of every calendar library. Test native date inputs and custom calendars according to their actual design. MDN documents that a native date input value uses yyyy-mm-dd even when its visible presentation is localised. The suite stores calendar dates without converting them into midnight timestamps.
The 30 cases below are a test design, not an execution report. Replace the example rules with approved requirements before recording pass or fail. Performance budgets and supported device versions must be agreed before execution.
Selection and calendar navigation
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D01 | Functional | Select 2028-02-10 as both start and end | One-day range is accepted and review shows the selected date |
| D02 | Functional | Select 2028-03-01 through 2028-03-03 | Both dates persist unchanged after save and reload |
| D03 | Functional | Move from February to March and back before choosing | Navigation alone does not change the selected value |
| D04 | Functional | Open the picker with an existing saved date | Selected date is identified in the correct month |
| D05 | Functional | Use the available month or year navigation | Displayed month/year and day grid stay in agreement |
| D06 | Negative | Clear the required start field and submit | Required error prevents save without reusing its previous value |
| D07 | Functional | Reset the form to its initial empty state | Both dates and range highlighting are cleared |
| D08 | UI | Dismiss a custom popup without selecting a new day | Previous committed date remains and focus returns to its trigger |
Calendar and range boundaries
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D09 | Boundary | Select 2028-02-01 | Inclusive minimum is accepted |
| D10 | Boundary | Submit 2028-01-31 | Date is rejected as before the allowed range |
| D11 | Boundary | Select 2028-03-31 | Inclusive maximum is accepted |
| D12 | Boundary | Submit 2028-04-01 | Date is rejected as after the allowed range |
| D13 | Boundary | Select 2028-02-29 | Leap day is accepted and persists as February 29 |
| D14 | Negative | Submit the impossible date 2028-02-30 | Invalid date is rejected without silently rolling into March |
| D15 | Negative | Submit the non-leap date 2027-02-29 directly | Server rejects it as an invalid calendar date |
| D16 | Negative | Choose the blocked date 2028-02-15 | Selection or submission is refused with the unavailability reason |
| D17 | Negative | Choose February 14 through February 16 | Range is rejected because it crosses the blocked date |
| D18 | Negative | Set end date earlier than start date | Error identifies the invalid range and save is prevented |
| D19 | Functional | Change start date to after an already selected end date | End is cleared or flagged before submission; stale invalid range cannot save |
| D20 | Boundary | Change from March 31 to February in a custom month selector | No impossible February 31 value can be committed |
Locale, timezone and server validation
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D21 | Compatibility | Select March 4 in each supported locale | Visible formatting may differ; submitted value still represents 2028-03-04 |
| D22 | Negative | Enter an ambiguous date in a custom text field | It is parsed only according to the displayed format or rejected with format guidance |
| D23 | Compatibility | Save a date in Asia/Kolkata and reopen in a supported western timezone | Stored calendar date is unchanged |
| D24 | Boundary | In a relative-today variant, cross midnight in the configured business timezone | Earliest allowed date updates according to that timezone and approved rule |
| D25 | Security | Bypass disabled cells and submit a blocked date directly | Server rejects it independently of calendar UI |
| D26 | Security | Send malformed or excessive date text to the date endpoint | Controlled validation error occurs without an internal error or unintended record |
Accessible and responsive interaction
| ID | Category | Test case | Expected result |
|---|---|---|---|
| D27 | UI | Operate a custom calendar with keyboard alone using its documented model | User can open, move focus, select and dismiss without a mouse |
| D28 | UI | Read selected, focused and unavailable days with a screen reader | Full dates and relevant states are distinguishable; colour is not the only cue |
| D29 | Performance | Open the calendar and change months under agreed device/network conditions | Rendering and availability lookups meet the budget without stale enabled dates |
| D30 | Compatibility | Repeat limits and leap-day selection on supported native mobile and desktop pickers | Accepted values agree even though picker appearance and interaction differ |
Evidence and prioritisation
Prioritise D09–D18 and D23: they expose boundary, calendar and date-shift defects. Record the visible text, submitted date, stored value, locale and timezone. For native inputs, test semantic outcomes rather than demanding identical popup screenshots across browsers. The follow-up about daylight-saving time belongs to date-time scheduling; do not mix that with a date-only booking field. A custom calendar also needs the keyboard and focus review described in the WAI date-picker example.
Downloads
Quick answers
Should a date picker look identical in every browser?
No. Native pickers vary; validate the chosen date, constraints and usability on supported platforms.
Does HTML validation replace server validation?
No. Direct requests can bypass the picker and must be checked against the same business rules.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.