Как тестировать форму с вводом даты и кнопкой, выдающей день недели?
Что проверяют
Классическое задание на тест-дизайн: видите ли вы классы эквивалентности не только на входе, но и на выходе, и знаете ли подводные камни календаря. Следом спрашивают, как вы проверите правильность дня недели, не считая его в уме.
Как отвечать
Начните с уточнений: формат ввода (ДД.ММ.ГГГГ или выбор в календаре), допустимый диапазон лет, язык названий дней, что показывается при ошибке.
Каркас:
- классы на выходе: результатов семь, значит нужно минимум семь дат, по одной на каждый день. Особенно воскресенье: в JavaScript
getDay()возвращает для него 0, отсюда частый сдвиг на единицу; - високосные годы: 29.02.2024 существует, 29.02.2023 нет. Правило с исключениями: 1900 не високосный (делится на 100), 2000 високосный (делится на 400). Обе даты 29.02 обязательны;
- невалидные даты: 31.04, 00.01, 32.12, месяц 13, пустое поле, буквы, лишние пробелы;
- границы: минимальный и максимальный год и значения за ними, переход через 31.12 и 01.01;
- формат и локаль: 03.04 это 3 апреля или 4 марта? Двузначный год, другие разделители, вставка из буфера;
- часовой пояс:
new Date("2024-03-10")в JavaScript разбирается как полночь UTC, аgetDay()считает по местному времени. Западнее Гринвича пользователь увидит предыдущий день. Ловится сменой часового пояса системы.
Оракул нужен независимый: календарь, date в терминале или datetime.date(2024, 2, 29).strftime("%A") в Python. Для автотеста таблица «дата и ожидаемый день» прогоняется параметризованно.
Отдельный вопрос к требованиям: даты до 1582 года, когда григорианского календаря ещё не было. datetime в Python и Date в JavaScript считают по пролептическому григорианскому календарю, а старый GregorianCalendar в Java до 1582 года переходит на юлианский, и дни недели расходятся.
Где спотыкаются
Проверяют пять случайных дат и не покрывают все семь дней.
Забывают про 1900 год и считают високосным любой год, кратный четырём.
Не меняют часовой пояс, а именно там живёт самый неприятный баг таких форм.