Как тестировать Datepicker

Стратегия тестирования компонента Datepicker

Тестирование Datepicker — комплексная задача, требующая проверки функциональности, UI/UX, доступности, производительности и интеграции. Вот мой подход, основанный на десятилетиях опыта.

1. Функциональное тестирование (ядро логики)

Основной функционал — это выбор даты. Проверяем:

• Выбор одиночной даты: Клик на день → дата появляется в поле.
• Выбор диапазона: Для "range picker" — выбор начала и конца. Важно проверить логику:

    *   Невозможно выбрать конечную дату раньше начальной.
    *   Выбранный диапазон корректно подсвечивается.

• Навигация:

    *   Переключение месяцев/лет с помощью стрелок.
    *   Возможность быстрого перехода к текущей дате ("Today").
    *   Выбор месяца/года из выпадающих списков.

• Валидация и ограничения:

    *   **Min/Max даты:** Невозможно выбрать дату вне разрешенного диапазона. Такие даты должны быть disabled (заблокированы).
    *   **Disabled дни:** Конкретные дни недели (например, выходные) или даты из черного списка.
    *   **Ввод с клавиатуры:** Корректный парсинг строки в дату и обратная валидация.

• Очистка: Наличие и работа кнопки/иконки очистки поля.

Пример тест-кейса для валидации:

// Пример (псевдокод) проверки ограничений в E2E-тесте (Cypress/Playwright)
it('should not allow selecting date before minDate', () => {
    openDatepicker();
    // Предположим, minDate установлена на завтра
    const yesterday = getDate(-1); // функция, возвращающая вчерашнюю дату
    clickOnCalendarDay(yesterday);
    // Ожидаем: дата не выбрана, день остается неактивным
    expect(getSelectedDate()).to.be.null;
    expect(getCalendarDay(yesterday)).to.have.class('disabled');
});

2. UI/UX и кроссбраузерное тестирование

• Внешний вид и соответствие макетам: Размеры, шрифты, цвета, иконки, состояние hover/focus/active на интерактивных элементах.
• Позиционирование: Datepicker корректно открывается относительно поля ввода (снизу, сверху, прилегает к краям экрана).
• Закрытие: Клик вне области Datepicker, нажатие Esc, выбор даты.
• Адаптивность: Корректное отображение и использование на мобильных устройствах. Часто на мобилках используется нативный <input type="date">.
• Кроссбраузерность: Chrome, Firefox, Safari, Edge. Особое внимание — кастомному стилю в WebKit (Safari) и Firefox.

3. Тестирование доступности (A11y)

Критически важный аспект, часто упускаемый.

• Keyboard navigation: Полная навигация с клавиатуры.

    *   `Tab` фокусируется на поле ввода.
    *   `Space` или `Enter` открывает календарь.
    *   **Стрелки** перемещают фокус по дням.
    *   `Page Up/Down` переключают месяцы.
    *   `Enter` выбирает сфокусированную дату.

• ARIA-атрибуты: У компонента должны быть правильные роли (role="dialog", role="grid"), состояния (aria-expanded, aria-selected) и labels (aria-label для дней).
• Скринридеры: Проверка с NVDA (Windows) или VoiceOver (macOS). Озвучивание должно быть логичным: "Календарь, июль 2024", "29 июля, понедельник, выбрано".

4. Интеграционное и API-тестирование

Datepicker редко живет в вакууме.

• Связь с полем ввода: Выбранная дата корректно форматируется и отображается в input.
• Форматирование даты: Проверка разных форматов вывода (DD.MM.YYYY, YYYY-MM-DD).
• Язык и локализация: Корректное отображение названий месяцев и дней недели на разных языках, первый день недели (Пн vs Вс).
• Работа с формами: При отправке формы выбранная дата корректно передается на сервер (проверка через сетевые запросы).
• Взаимодействие с состоянием приложения (для SPA): Если выбрана дата, это может влиять на другие компоненты (например, обновление графика). Нужны интеграционные тесты.

5. Производительность и нагрузочное тестирование (для сложных кейсов)

• Рендеринг при быстрой навигации: Быстрое переключение между месяцами/годами не должно вызывать лагов или "падений" интерфейса.
• Инициализация: Одновременное открытие множества Datepicker'ов на странице (в админ-панелях).

6. Автоматизация

Ручное регрессионное тестирование Datepicker после каждого изменения неэффективно. Автоматизируем:

• Unit-тесты (Jest, Vitest): Логика валидации, вычисления диапазонов, форматирования.

// Пример unit-теста для функции ограничения даты
import { clampDate } from './datepickerUtils';

describe('clampDate function', () => {
    const minDate = new Date('2024-01-10');
    const maxDate = new Date('2024-01-20');

    test('should return the date itself if within range', () => {
        const date = new Date('2024-01-15');
        expect(clampDate(date, minDate, maxDate)).toBe(date);
    });

    test('should return minDate if date is earlier', () => {
        const date = new Date('2024-01-05');
        expect(clampDate(date, minDate, maxDate)).toBe(minDate);
    });
});

• Компонентные тесты (Testing Library): Рендеринг, симуляция кликов, проверка состояний.
• E2E-тесты (Cypress, Playwright): Полные сценарии взаимодействия пользователя в реальном браузере (открытие, выбор, проверка значения в поле).

Ключевые сценарии для чек-листа

• Выбор даты в текущем месяце.
• Выбор даты в следующем/предыдущем месяце.
• Выбор даты с клавиатуры (ввод в поле).
• Выбор недопустимой даты (заблокированной) → ожидаемое поведение (игнорирование/сообщение).
• Работа Datepicker внутри модального окна или скроллящейся страницы (проблемы с z-index и позиционированием).
• Быстрое последовательное открытие-закрытие.

Вывод: Тестирование Datepicker — это не просто "кликнуть на число". Это многослойная проверка, где функциональность, доступность и интеграция одинаково важны. Начинать следует с unit-тестов для бизнес-логики, затем покрывать компонентными тестами рендер и интерактивность, а ключевые пользовательские потоки автоматизировать в E2E. Ручное тестирование оставить для UX-проверок и сложных визуальных кейсов.