Тестирование переводов

Природа тестирования переводов

Тестирование интернационализации отличается от классического тестирования логики тем, что проверяется не поведение алгоритма, а согласованность и полнота текстового слоя приложения. Переводы становятся частью интерфейса, а значит подчиняются тем же требованиям предсказуемости, что и UI-компоненты: стабильность, воспроизводимость, отсутствие регрессий.

В экосистеме FormatJS сообщения формируются как структурированные ICU-строки, что позволяет тестировать их не как «строки текста», а как формальные выражения с параметрами, множественными формами и форматированием.


Структура сообщений и тестируемые свойства

Сообщения в FormatJS строятся вокруг ICU MessageFormat:

  • параметры ({name})
  • числа ({count, number})
  • даты ({date, date})
  • выбор форм (select, plural)
  • вложенные конструкции

Тестирование переводов в этом контексте затрагивает не только текст, но и корректность интерпретации структуры сообщения.

Ключевые свойства, подлежащие проверке:

  • корректность ICU-синтаксиса
  • наличие всех ключей сообщений
  • согласованность параметров между локалями
  • отсутствие «битых» плейсхолдеров
  • корректная работа plural rules для разных языков

Валидация извлечённых сообщений

FormatJS предоставляет инструменты CLI для извлечения сообщений из кода (@formatjs/cli). На этапе тестирования важно проверять, что извлечённые сообщения совпадают с эталонной структурой.

Типичный сценарий проверки:

  • извлечение сообщений из исходного кода

  • сравнение с эталонным JSON-каталогом

  • выявление:

    • отсутствующих ключей
    • устаревших ключей
    • изменённых ICU-выражений

Подобная проверка обычно оформляется как отдельный шаг CI и может быть реализована через diff JSON-структур.


Юнит-тестирование компонентов с intl

В React-среде тестирование компонентов с переводами требует подмены контекста IntlProvider. Основная цель — изолировать компонент от внешних файлов локализации и обеспечить детерминированный вывод.

Пример типовой стратегии:

  • фиктивный IntlProvider с одной локалью
  • фиксированный набор сообщений
  • контроль форматирования через стабильный locale (например, en)

Особое внимание уделяется:

  • корректной подстановке параметров
  • отображению fallback-строк
  • отсутствию необработанных ключей (missing translation leakage)

При тестировании важно исключить влияние реального окружения браузера, особенно Intl API, если требуется строгая повторяемость.


Проверка параметризации сообщений

Одним из критических аспектов является проверка передачи параметров в сообщения.

Проблемные случаи:

  • пропущенные параметры → пустые строки или ошибки форматирования
  • лишние параметры → неиспользуемые данные
  • несовпадение типов (например, строка вместо числа)

Тестирование строится вокруг подстановки фиктивных данных:

  • числовые значения для plural
  • даты в фиксированном формате
  • строки с символами, влияющими на ICU-синтаксис

Snapshot-тестирование переводов

Snapshot-тестирование применяется для контроля стабильности визуального текста интерфейса.

Основная идея:

  • рендер компонента с фиксированной локалью
  • сохранение текстового дерева
  • сравнение с эталонным снапшотом

Риски snapshot-подхода:

  • чувствительность к изменениям формулировок
  • ложные срабатывания при изменении переводов без изменения логики
  • зависимость от конкретной локали

Поэтому snapshot-тестирование чаще используется как дополнительный слой, а не основной механизм контроля.


Псевдолокали и стресс-тестирование интерфейса

Для проверки устойчивости интерфейса применяется псевдолокаль, например:

  • удлинённые строки
  • добавление диакритических символов
  • зеркальное отображение текста (RTL-симуляция)
  • замена символов на расширенные Unicode-аналоги

Цель такого тестирования — выявить:

  • переполнение контейнеров
  • обрезание текста
  • поломку верстки из-за длины строк
  • некорректную обработку Unicode

FormatJS позволяет легко подставлять псевдолокали через стандартный механизм IntlProvider.


Проверка ICU-синтаксиса

ICU-строки требуют строгого синтаксического соответствия. Ошибки часто возникают при ручном редактировании переводов.

Типовые проблемы:

  • незакрытые фигурные скобки
  • неверные типы форматирования (number, date, plural)
  • нарушение вложенности select и plural
  • несоответствие параметров между локалями

Для автоматической проверки применяются парсеры ICU, которые могут быть встроены в тестовый пайплайн. Любое сообщение должно успешно проходить парсинг без исключений.


Тестирование отсутствующих ключей и fallback-логики

Fallback-механизм является критически важной частью системы интернационализации.

Проверяется поведение при:

  • отсутствии ключа в текущей локали
  • отсутствии ключа во всех локалях
  • частично переведённых каталогах

Корректная система должна:

  • возвращать дефолтное сообщение
  • или отображать ключ (в зависимости от конфигурации)
  • фиксировать отсутствие перевода в логах

Тесты обычно строятся на искусственно урезанных наборах локалей.


Проверка согласованности переводов между локалями

Система сообщений должна сохранять структуру при переводе:

  • одинаковые параметры
  • одинаковые ICU-структуры
  • отсутствие изменения логики выражений

Типовой тест сравнивает:

  • набор ключей
  • структуру параметров внутри сообщений
  • наличие обязательных сегментов plural/select

Любое расхождение трактуется как ошибка синхронизации переводов.


Тестирование чисел, дат и локализационных форматов

FormatJS активно использует Intl API для форматирования значений.

Проверке подлежат:

  • формат чисел (разделители, округление)
  • отображение процентов
  • формат дат (короткий/длинный)
  • часовые пояса

Тестирование строится на фиксированных входных данных и строгом сравнении выходных строк.

Особое внимание уделяется различиям локалей, где:

  • десятичный разделитель отличается
  • порядок даты меняется (DD/MM vs MM/DD)
  • используются разные системы счисления

Интеграция тестирования переводов в CI

В рамках CI-пайплайна тестирование интернационализации обычно разбивается на несколько этапов:

  • проверка извлечения сообщений
  • валидация ICU-синтаксиса
  • unit-тесты компонентов
  • snapshot-проверки
  • проверка полноты переводов

Каждый этап блокирует сборку при обнаружении ошибок, связанных с:

  • отсутствующими ключами
  • нарушенной структурой сообщений
  • несовместимостью параметров
  • регрессиями в UI-тексте

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