5.6 KiB
Что подтверждают проверки системы
Успешная сборка, запуск, равенство схем и прохождение пользовательского сценария — разные доказательства. Выбор проверки зависит от наблюдаемого риска: денежных вычислений, доступа, целостности данных или состояния интерфейса. Общие основания описаны в принципах сопровождения.
Интерфейс
Локальный gate frontend охватывает типы, статический анализ, автоматические сценарии, зависимости и сборки приложения и UI-каталога. Он выполняется без запущенного backend. Покрытие ограничивает регрессии, но не доказывает правильность финансового расчёта, доступность и полный пользовательский сценарий.
Каталог показывает существующие визуальные решения на вымышленных данных. Широкий и узкий экран, клавиатурная навигация, восстановление после ошибок и соответствие задаче проверяются в интерфейсе отдельно от сборки. Изолированная тестовая среда не воспроизводит все свойства браузера и живой интеграции.
API и хранение данных
Локальный gate backend объединяет статический анализ, типы приложения и тестов, автоматические сценарии и сборку. Он не исправляет исходные файлы; автоматическое форматирование выполняется отдельно и не является доказательством. Диагностика покрытия доступна без общего числового порога.
Равенство OpenAPI подтверждает согласованность публичного описания с клиентом. Валидация, cookie, авторизация счёта, статусы и ошибки требуют полного HTTP-потока; целостность и конкурентные изменения данных — проверки с изолированной реальной базой. Подставной ответ базы не доказывает её транзакционные свойства. Направление генерации и границы сравнения — в проверке OpenAPI.
Известное ограничение сквозной проверки
Прежний blocker WL-P2-05 снят в конфигурации Prisma: на Node 22.21.0 /
Prisma 7.9.1 унаследованный RUST_LOG=warn или error воспроизводит пустой
Schema engine error, а отсутствие переменной позволяет fresh migration.
Backend Prisma config удаляет переменную в процессе CLI после загрузки .env;
это не меняет application logging. Версии зависимостей и SQL history сохранены.
npm run test:e2e применяет migrations и запускает каждую HTTP suite на отдельной
временной DB. Один URL передаётся Prisma и Jest; прямой запуск Jest без runner
отклоняется до DB-запросов. При ошибке и SIGINT/SIGTERM выполняется cleanup.
npm run test:sqlite выбирает auth/cards; test:durability отдельно проверяет
migration, restart, возврат предыдущего приложения и backup/restore.
Команды и runnable regression — в
backend README,
фактические результаты — в
registry.
Backend verify остаётся статическим/unit/build gate; полный HTTP/DB scope
проверяется отдельным test:e2e. Успех этих команд не подтверждает доступность
внешнего T-Bank. HTTP tests требуют локальных портов, которые sandbox может
запрещать. Безопасное сохранение реальных данных — в
локальном окружении.
Где выполнять проверки
Команды и конкретные тестовые правила поддерживаются в локальных инструкциях frontend и backend. Проверки этой документации — в CONTRIBUTING. Отчёт различает пройденную границу, оставшееся ограничение и проверяемое состояние; успех одного gate не распространяется автоматически на весь workspace.