Какие проблемы могут возникнуть с типами данных на границах

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

Умеете ли вы находить границы не только в требованиях, но и в самих типах данных и на стыках систем: UI, API, база, внешний сервис. Следом часто просят назвать конкретные значения для поля «возраст» или «сумма» и объяснить, откуда они взялись.

Как отвечать

Анализ граничных значений строится вокруг min-1, min, max, max+1, но границы задают не только требования. Их задаёт тип хранения, и на каждом слое он может быть своим:

• целые числа: int32 заканчивается на 2147483647, следующее значение даёт переполнение или ошибку. Проверьте, что «безлимитное» количество не упирается в smallint в базе;
• большие ID в JavaScript: Number.MAX_SAFE_INTEGER равен 2^53-1, и 64-битный ID из JSON на фронтенде тихо искажается. Такие ID отдают строкой;
• дробные: 0.1 + 0.2 во float не равно 0.3, деньги во float теряют копейки. Проверяйте округление на суммах с тремя знаками после запятой;
• строки: длина в символах и в байтах разная. VARCHAR(50) в PostgreSQL считает символы, а эмодзи в JavaScript даёт length 2. Проверяйте максимум кириллицей и эмодзи, а не только латиницей;
• даты и время: 29 февраля, конец месяца, переход на летнее время, часовые пояса на стыке сервисов, 32-битное Unix-время, которое заканчивается 19 января 2038 года;
• пустые значения: пустая строка, пробелы, null, отсутствующее поле и 0 это разные случаи, и обрабатываться они должны одинаково на всех слоях;
• приведение типов на входе API: "123" вместо 123, "true" вместо true, десятичная запятая вместо точки.

Хороший приём: сверить лимиты по слоям. Форма пропускает 255 символов, API 200, колонка 100, и пользователь получает ошибку 500 вместо понятного сообщения.

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

Берут границы только из требований и не смотрят в схему базы и контракт API, где лимиты часто другие.

Проверяют длину строки латиницей. Кириллица и эмодзи занимают больше байт и ломают поля, которые считают байты.

Путают null, пустую строку и отсутствующее поле, заводя на них один тест вместо трёх.