Тестирование frontend-приложений¶

Требования этого документа применяются к тестированию frontend-приложений профилей CSR, SSR, SSG и edge по frontend/rendering-profiles.md. Дополнительные границы профилей проверяются применимыми требованиями FE-PROF. Уровни обязательности определены в корневом README.md.

Общие свойства проверок, включая воспроизводимость и изоляцию данных, регулируются DEV-VER-001–DEV-VER-007; этот документ задаёт только frontend-специфичные свойства тестов.

В этом документе:

unit-тест проверяет одну единицу логики в памяти процесса без DOM;
component-тест проверяет отрисовку и поведение компонента в изолированном DOM;
e2e-тест проверяет развёрнутое приложение через публичный интерфейс браузера;
test double — общее название mock, stub, fake и spy.

FE-TST-006. Область unit-теста¶

Уровень: MUST

Применяется к: unit-тестам

Unit-тест должен выполняться в одном процессе и не обращаться к DOM, сети, файловой системе, реальному backend или системным часам. Зависимость от таких ресурсов должна передаваться через явную границу и заменяться контролируемым test double.

Обоснование¶

Изолированный unit-тест быстро и точно локализует ошибку логики.

Проверка¶

запуск без сетевого доступа и DOM;
review зависимостей тестируемой единицы;
контроль времени выполнения unit-набора.

Исключения¶

Чтение неизменяемого fixture-файла допускается, если парсинг является предметом теста.

FE-TST-007. Область component-теста¶

Уровень: SHOULD

Применяется к: component-тестам

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

Тесту не следует проверять внутреннюю последовательность вызовов реализации. DOM, не наблюдаемый пользователем, не должен быть единственным предметом assertion.

Обоснование¶

Поведенческий тест устойчив к рефакторингу и проверяет то, что видит пользователь.

Проверка¶

пробный рефакторинг без изменения поведения;
review assertions на наблюдаемость;
проверка доступности ключевых компонентов при доступности инструмента.

Исключения¶

Spy внутреннего события допускается для недоступного иначе значимого эффекта с обоснованием.

FE-TST-008. Contract-тест против backend API¶

Уровень: MUST

Применяется к: клиенту backend API

Набор должен содержать contract-тест, проверяющий, что клиент API и его tolerant reader по FE-API-002 корректны относительно зафиксированной версии контракта. Тест должен проверять сценарии успеха, protocol error, timeout и некорректного ответа.

Клиент может проверяться по OpenAPI, JSON Schema или иному версионируемому контракту; реальный backend может заменяться contract-validated test double.

Обоснование¶

Большинство дефектов интеграции возникает на границе форматов и частичных отказов.

Проверка¶

contract-тест каждого класса исхода;
проверка tolerance к неизвестным полям;
review соответствия версии test double версии контракта.

Исключения¶

Sandbox backend следует использовать вместо test double, если он стабилен и доступен в CI.

FE-TST-009. Область и среда e2e-теста¶

Уровень: MUST

Применяется к: автоматизированным e2e-тестам

E2e-тест должен взаимодействовать с развёрнутым приложением только через публичный интерфейс браузера. Среда должна развёртываться автоматически из проверяемых артефактов одного commit. Прямое изменение внутренней базы или вызов внутреннего метода для проверяемого действия запрещены.

Собственные сервисы проверяемого потока не должны заменяться mock; внешняя система вне контроля проекта может заменяться contract-validated test double.

Обоснование¶

E2e-тест подтверждает пользовательский контракт и совместную работу компонентов.

Проверка¶

сопоставление commit SHA и версий артефактов;
review использованных браузеров и credentials;
проверка недоступности setup-интерфейса в production.

Исключения¶

Проверка обратной совместимости может намеренно использовать несколько версий.