Test Cases for Date Picker: Calendar QA Examples

A booking selected for March 31 can become March 30 after an API round trip if the browser, server, and database disagree about time zones. The calendar may still highlight the expected square, so a visual click test passes while the stored business date is wrong.

Date-picker coverage must connect what the user sees, what the control submits, and what the product later displays. Before enumerating calendar cells, establish whether the value is a date, a local date-time, or an instant. That decision controls almost every meaningful expected result.

Write the Temporal Contract First

Record the allowed range, disabled dates, week start, supported calendars, locale behavior, input format, output format, and whether manual typing is allowed. For a range picker, define whether the end is inclusive, whether same-day ranges are valid, and how minimum or maximum duration is calculated.

Clarify the meaning of “today.” A travel booking may use the property's time zone, while a task deadline may use the account's zone. If the rule follows the device zone, specify what happens when the zone changes after selection. Freeze the clock in automated tests so midnight does not make results intermittent.

Partition the Calendar Around Boundaries

Do not click every day equally. Choose representatives at rule boundaries: earliest allowed, one day before, latest allowed, one day after, today, yesterday, tomorrow, first and last day of a month, year transition, and a leap day. Include February 29 in a leap year and reject it in a non-leap year.

Exercise months with 28, 29, 30, and 31 days. Move from January 31 to February and from December to January. If the widget supports month or year selection, test the first and last selectable values plus large navigation jumps.

For business calendars, include weekends, holidays, blackout windows, sold-out dates, and a date whose availability changes while the picker remains open. Disabled days must be visually distinct, programmatically unavailable, and impossible to submit through typing or request manipulation.

Verify Single-Date Selection and Editing

Open the picker using pointer, keyboard, and any calendar icon. Confirm the expected month receives focus and the currently selected date is identified. Select a valid day and verify the visible field, accessible value, submitted payload, and persisted record all agree.

Test clearing, reopening, replacing a selection, pressing Escape, clicking outside, and submitting without a required date. If typing is supported, cover valid localized input, leading zeros, separators, pasted text, whitespace, partial dates, impossible dates, and extra characters. Decide whether parsing is strict or forgiving and keep that behavior consistent.

Check browser autofill and values restored from form history. A restored machine-formatted date should render in the active locale without firing duplicate change events or bypassing disabled-date rules. If the application auto-corrects input, show the normalized result before submission so the user can detect an unintended month or day swap.

Exercise Range Rules and Partial States

Select a start date and inspect the control before choosing an end. The temporary state should be understandable, and closing the picker must follow a defined commit or cancel policy. Then select an end before the start, the same day, one day later, and at minimum and maximum duration boundaries.

Confirm nights, days, or billing periods use the intended inclusion rule. A hotel stay from July 10 to July 11 is usually one night, while a report filter may include both calendar dates. The UI summary, price calculation, API payload, and later edit screen must all use the same rule.

Test changing only the start after both values exist, changing only the end, clearing one side, and selecting across disabled dates. If a rule automatically adjusts the other boundary, announce and display that change instead of silently altering the user's choice.

Cross Locales, Zones, and Clock Changes

Run representative cases in locales with different day-month order, separators, month names, week starts, and numeral systems. The selected value should survive a locale switch even though its display changes. Ambiguous typed text such as 03/04/2026 must follow the displayed format hint or be rejected clearly.

Test positive and negative UTC offsets, zones on opposite sides of the date line, and a browser zone different from the account or property zone. Save near local midnight and verify the chosen calendar date does not drift after refresh, notification, export, or API retrieval.

For date-time pickers, include daylight-saving gaps and overlaps. A nonexistent local time should not be accepted as if it existed. An ambiguous repeated time needs an offset or product rule that makes the instant unambiguous. Changing the operating-system clock while the picker is open should not bypass min-date or expiry rules enforced by the server.

Prove Keyboard and Screen-Reader Operation

The field, trigger, dialog, month controls, grid, and selected date need meaningful accessible names and states. Open the picker from the keyboard and confirm focus enters at the selected date or the documented default. Arrow keys should move by day or week according to the component pattern, while month navigation must not trap focus.

Verify today, selected, unavailable, and range states are exposed without relying on color. A screen reader should announce a complete date, not only “10.” Validation errors must be associated with the input, and closing the dialog should return focus to the trigger.

Test 200 percent zoom, high contrast, larger text, and reduced motion. Month names, weekday headers, and action buttons should not clip. A range highlight needs clear start and end indicators as well as the background between them.

Test Responsive Layout and Touch Behavior

On narrow screens, confirm the calendar fits without hiding days or actions. Rotate the device with an unfinished selection and verify state survives. Touch targets should be large enough and separated so adjacent dates are not selected accidentally.

Check scrolling when the software keyboard is open, especially if manual input and a calendar overlay coexist. The dialog should remain dismissible, and page scrolling should restore after it closes. Test browser back, native back, tap outside, and swipe gestures only where the design supports them.

Long month names and translated action labels often break layouts that looked correct in English. Include right-to-left rendering and ensure previous and next controls still represent chronological movement correctly.

Follow the Value Through the System

Intercept or inspect the submitted request and compare it with the visual selection. Refresh the page, reopen the record, view it from another time zone, and edit it. Check exports, confirmation emails, reminders, and calculations that consume the value. A correct picker can still feed a faulty serialization layer.

Attempt to submit disabled or out-of-range values directly to the API. Server validation must enforce the same business boundary because client restrictions are easy to bypass. When availability changes between selection and submission, preserve the user's input long enough to explain the conflict and offer a valid recovery.

Dynamic limits deserve a separate state check. Open the picker, then change the related field that controls availability, such as destination, service type, or account plan. The calendar should invalidate or retain the existing selection according to policy and announce the change. Simulate the availability service returning stale data, failing, and recovering. A cached calendar may remain browsable, but submission must revalidate the chosen date against current server rules. If two users compete for a limited slot, only the authoritative reservation step should decide the winner, and the losing user should return to the picker with their other form data intact.

For automation, assert accessible names and selected states rather than grid positions or generated CSS classes. Freeze the date and set locale and zone explicitly. Cover one stable success route, each temporal boundary, a range rule, a localization case, keyboard navigation, and the API rejection of an invalid value.

Use one forensic date trace near midnight and another range that crosses a month or year boundary. For each, record the selected label, submitted representation, stored value, reloaded display, and downstream output. Any disagreement identifies the layer that shifted the date, which a calendar-only click sequence cannot reveal.