Нужно ли проверять формат даты, ограничения по возрасту и корректность данных
Что проверяют
Умеете ли вы превратить общую фразу про валидацию в конкретный список проверок и знаете ли, что даты это поле с самым богатым набором граничных значений. Ещё смотрят, помните ли вы про уровни: форма, метод API, база.
Как отвечать
Разложите на три группы и по каждой назовите примеры.
Формат и разбор: несуществующие даты вроде тридцатого февраля, двадцать девятое февраля в невисокосном году, порядок дня и месяца, разделители, двузначный год, пустое поле, пробелы, вставка из буфера против выбора в календаре, ввод с клавиатуры в поле, где ожидали только календарь.
Бизнес-правила: дата рождения в будущем, неправдоподобно давняя дата, возрастной порог. Возраст считается от даты рождения на текущую дату, поэтому границы такие: день рождения ровно сегодня, день до и день после, отдельно рождённые двадцать девятого февраля.
Корректность в целом: что сохранилось в базе, в каком часовом поясе, как значение показывается обратно в форме, что происходит при редактировании и повторном сохранении.
Обязательно проговорите уровни: проверка на клиенте это удобство, а не защита. Тот же запрос надо отправить мимо формы и убедиться, что сервер отказал сам, иначе ограничение обходится через инструменты разработчика.
Где спотыкаются
Проверяют положительный сценарий и буквы в поле даты, считая это полным покрытием. Основная добыча сидит на границах: порог возраста минус один день, високосный год, переход через полночь.
Ограничиваются интерфейсом. Форма режет ввод, а метод API принимает любой год, или дата уезжает в хранилище в UTC и у пользователя в другом часовом поясе показывается вчерашней.
Придумывают ожидаемый результат за аналитика. Какой порог возраста, как он считается, что делать с датой без часового пояса, это вопросы к требованиям. Тестировщик, решивший их сам, либо закрывает настоящий дефект как задуманное поведение, либо заводит несуществующий.