github-ops
123 lines
4.0 KiB
Markdown
123 lines
4.0 KiB
Markdown
# Стратегия тестирования
|
||
|
||
## 1. Назначение документа
|
||
|
||
Этот документ фиксирует, как проект должен тестироваться с самого начала разработки, чтобы архитектура не осталась "только на бумаге".
|
||
|
||
Цель:
|
||
|
||
- проверять доменную модель отдельно от транспорта;
|
||
- ловить регрессии в mapping;
|
||
- не дать адаптерам начать вести себя по-разному;
|
||
- обеспечить воспроизводимость для демонстрации и регрессионных проверок.
|
||
|
||
## 2. Уровни тестов
|
||
|
||
### 2.1. Unit tests
|
||
|
||
Покрывают:
|
||
|
||
- `crank-schema`
|
||
- `crank-mapping`
|
||
- небольшие части `crank-core`
|
||
|
||
Что проверять:
|
||
|
||
- валидацию схем;
|
||
- `JSONPath` parsing;
|
||
- применение input/output mapping;
|
||
- генерацию чернового mapping;
|
||
|
||
### 2.2. Integration tests
|
||
|
||
Покрывают:
|
||
|
||
- `crank-registry` с реальной БД;
|
||
- `crank-runtime` с реальными adapter contracts;
|
||
- `admin-api` на поднятом приложении;
|
||
- publish flow и YAML import/export.
|
||
|
||
Что проверять:
|
||
|
||
- создание operation и новой version;
|
||
- publish и reload published tools;
|
||
- тестовый вызов draft;
|
||
- экспорт в YAML и повторный импорт;
|
||
- связность БД между `operations`, `operation_versions`, `published_operations`.
|
||
|
||
### 2.3. Adapter tests
|
||
|
||
Отдельно для Community-протокола:
|
||
|
||
- REST adapter;
|
||
|
||
Что проверять:
|
||
|
||
- сборку request;
|
||
- нормализацию response;
|
||
- обработку ошибок;
|
||
- стабильность mapping context.
|
||
|
||
### 2.4. End-to-end tests
|
||
|
||
Минимально нужны сценарии:
|
||
|
||
- создать REST operation -> протестировать -> опубликовать -> вызвать как MCP tool;
|
||
|
||
## 3. Что должно быть покрыто обязательно
|
||
|
||
### Обязательно с первого этапа
|
||
|
||
- schema validation;
|
||
- mapping execution;
|
||
- YAML import/export roundtrip;
|
||
- versioning logic registry;
|
||
- publish flow.
|
||
|
||
### Обязательно до первого демо
|
||
|
||
- хотя бы один end-to-end сценарий для REST;
|
||
- negative tests на invalid `JSONPath`;
|
||
|
||
## 4. Формат тестовых данных
|
||
|
||
Рекомендуется использовать:
|
||
|
||
- JSON fixtures для sample input/output;
|
||
- YAML golden files для export/import;
|
||
- snapshot tests для generated draft.
|
||
|
||
## 5. Техническая стратегия
|
||
|
||
Для Rust-части:
|
||
|
||
- unit/integration tests через `cargo test`;
|
||
- тестовые фикстуры в `tests/fixtures/`;
|
||
- golden files для YAML;
|
||
- отдельные integration suites для registry и admin-api.
|
||
|
||
Для frontend:
|
||
|
||
- unit tests для form helpers и schema rendering;
|
||
- integration tests для critical user flows;
|
||
- отдельная проверка mapping editor и sample upload flows.
|
||
- отдельный regression checklist для post-integration smoke pass: [manual-regression-checklist.md](manual-regression-checklist.md).
|
||
|
||
## 6. Что нельзя оставлять без тестов
|
||
|
||
- version increment logic;
|
||
- publish semantics;
|
||
- YAML import как `create|upsert`;
|
||
- auth profile resolution;
|
||
- generated draft application;
|
||
- MCP tool execution path.
|
||
|
||
## 7. Практический итог
|
||
|
||
Перед активной разработкой проект должен исходить из правила:
|
||
|
||
- доменная логика тестируется отдельно;
|
||
- adapters тестируются отдельно;
|
||
- registry и admin-api тестируются на реальной БД;
|
||
- минимум один полный end-to-end сценарий должен быть воспроизводим автоматически.
|