Какие проверки сделать для поля имя, дата рождения и чекбокса

Что проверяют

Как вы проектируете проверки для полей разной природы: текст, дата и булево значение требуют разных техник. Интервьюер смотрит, найдёте ли вы неочевидные границы в дате и юридический смысл чекбокса. Следом часто просят назвать тесты на возрастное ограничение.

Как отвечать

Начните с требований к каждому полю, потом по порядку.

Имя:

• обязательность: пусто, одни пробелы, пробелы по краям обрезаются;
• символы: кириллица, латиница, «ё», дефис и апостроф в двойных и иностранных именах;
• длина: границы с обеих сторон, например 1, 2, 3 при минимуме 2 и 49, 50, 51 при максимуме 50.

Дата рождения:

• формат: ручной ввод и выбор в календаре дают одно значение, ДД.ММ.ГГГГ не путается с американским ММ/ДД/ГГГГ;
• несуществующие даты: 31.04, 30.02, 29.02 в невисокосный год, при этом 29.02.2024 корректна;
• логика: будущая и сегодняшняя дата отклоняются, слишком старая тоже, если есть нижняя граница;
• возраст: при минимуме 18 лет тот, кому 18 исполнилось сегодня, проходит, а тот, у кого день рождения завтра, нет. Отдельно родившиеся 29 февраля;
• часовой пояс: дата не сдвигается на день при сохранении, частый баг при хранении даты как времени в UTC.

Чекбокс:

• по умолчанию: согласие на обработку данных не отмечено заранее;
• обязательность: без отметки форма не отправляется или кнопка неактивна, а сообщение объясняет причину;
• взаимодействие: переключается кликом по подписи и пробелом, состояние не сбрасывается после ошибки в другом поле;
• сервер: значение сохраняется, запрос без него через API отклоняется.

Где спотыкаются

Проверяют дату парой примеров и не трогают 29 февраля, конец месяца и границу возраста ровно в день рождения.

Считают чекбокс тривиальным. А это юридически значимое согласие, и отмеченный заранее флажок это дефект, а не удобство.

Не проверяют сохранение. Форма показывает правильную дату, а в базе оказывается предыдущий день из-за перевода в UTC.