Как задавать короткие и длинные текстовки для проверки UI?

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

Умеете ли вы применять граничные значения к тексту и знаете ли, где длина строки ломает интерфейс: обрезка, перенос, наезд элементов друг на друга. Следом спрашивают, как вы подставите такие данные, если через обычный интерфейс длинный текст не ввести.

Как отвечать

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

• границы: пустая строка, один символ, максимум, максимум плюс один. Отдельно строка из одних пробелов и пробелы по краям;
• длинное без пробелов: URL, email, длинное составное слово. Такие строки не переносятся по словам и распирают контейнер;
• локализация: немецкий и русский заметно длиннее английского, а в арабском и иврите интерфейс зеркалится. Для проверки есть псевдолокали: en-XA и ar-XB в Android, удвоенная длина строк и RTL-псевдоязык в настройках схемы Xcode;
• символы: эмодзи, диакритика, спецсимволы вроде <script> и кавычек, которые ломают разметку или экранирование;
• масштаб шрифта: крупный шрифт в настройках системы, Dynamic Type на iOS. Короткая подпись кнопки внезапно становится длинной.

Способы подставить текст: через API или сиды в базе, подменой ответа в Charles или Proxyman, правкой DOM в DevTools для быстрой проверки вёрстки. В автотестах такие строки идут параметрами, а скриншотные тесты ловят обрезку.

Проверяйте текст не только в поле ввода, но и везде, где он потом показывается: в списке, карточке, пуш-уведомлении, письме.

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

Берут один «средний» Lorem ipsum и считают, что длинный текст проверен. Граница при этом не тронута, а ломается обычно на ней.

Считают длину в символах, когда ограничение в байтах. Кириллица в UTF-8 занимает два байта, многие эмодзи четыре, а length в JavaScript считает такой эмодзи за два символа.

Не сверяют лимиты фронта и бэкенда: форма пропускает 300 символов, колонка хранит 255, и пользователь получает ошибку 500 вместо понятного сообщения.