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

Parano1d использует три слоя тестов: инварианты отдельных крейтов, межмодульные релизные тесты и интеграционные сценарии в отдельных процессах.

Быстрые проверки

Перед локальным изменением:

cargo fmt --all -- --check
cargo check --locked --workspace --all-targets
cargo test --locked -p CHANGED_CRATE

Для протокольного кода добавляйте непосредственно зависящие крейты. Изменение транзакции обычно требует как минимум:

cargo test --locked \
  -p noid_tx \
  -p noid_chain \
  -p noid_mempool \
  -p noid_miner \
  -p noid_rpc \
  -p noid_node

Вычислительные ядра системы доказательств

Тесты штатных вычислительных ядер запускаются в релизном режиме:

cargo test --locked --release \
  -p noid_core \
  -p noid_poseidon2b \
  -p noid-ivc-core

На x86-64 принудительно проверьте минимальную штатную реализацию:

NOID_CPU_BACKEND=pclmul \
  cargo test --locked --release \
  -p noid_core -p noid_poseidon2b -p noid-ivc-core

Скалярная реализация используется только для дифференциальной проверки:

NOID_CPU_BACKEND=scalar \
  cargo test --locked --release \
  -p noid_core -p noid_poseidon2b

Обязательные проверки релиза

scripts/build_release.sh аутентифицирует канонический пакет матриц, встраивает его, выполняет набор нативных релизных тестов и быстро проверяет запуск:

предварительную проверку оборудования;
справку ноды и границу запуска;
CLI;
внешний майнер;
self-check упакованного GUI.

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

Интеграционные сценарии с реальными процессами

Сценарии создают чистые каталоги под target/live-tests. Они запускают настоящие процессы, RPC, P2P, MDBX и штатный конвейер доказательств.

Сценарий	Покрытие
`live_single_transaction_scenario.py`	Кошелёк → мемпул → майнер → канонический блок
`live_multi_transaction_mempool_scenario.py`	Три непротиворечивые логические транзакции и ретрансляция
`live_large_mempool_single_miner_scenario.py`	Обработка 128 логических транзакций блоками B64
`live_large_mempool_two_miners_scenario.py`	Большой мемпул при конкуренции майнеров
`live_two_miner_fork_reorg_scenario.py`	Конкурирующие ответвления и неглубокая реорганизация
`live_connected_miner_restart_sync_scenario.py`	Перезапуск майнеров и защита от устаревшего родителя
`live_mining_peer_gate_scenario.py`	Обычный кворум пиров
`live_sync_scenarios.py`	Чистая синхронизация и границы 5/19 блоков
`live_incremental_snapshot_scenario.py`	Полная и инкрементальная публикация снимка
`live_sync_announced_tip_scenario.py`	Догоняющая синхронизация до объявленной вершины цепи
`live_state_restart_scenario.py`	Перезапуск компактного `State` и первый новый блок
`live_state_slot_lifecycle_scenario.py`	Очистка, повторное использование, плотность и перезапуск слотов
`live_receipt_lifecycle_scenario.py`	Сохранение, подмена, перезапуск и проверка чека после удаления тела
`live_wallet_active_address_scenario.py`	Создание, пополнение, активация и сохранение владельцев
`live_wallet_mining_payout_switch_scenario.py`	Атомарная смена владельца выплаты
`live_wallet_receive_online_scenario.py`	Инкрементальное обновление получателя онлайн
`live_wallet_receive_offline_shallow_scenario.py`	Восстановление получателя по сохранённым блокам
`live_wallet_receive_offline_snapshot_scenario.py`	Восстановление получателя через синхронизацию по снимку
`live_slot_mempool_wallet_scenarios.py`	Salted-подсказки, отправки между нодами и сходимость
`live_p2p_identity_handshake_scenario.py`	Постоянный peer ID и симметричное установление соединения
`live_p2p_fan_in_scenario.py`	Нагрузка при параллельном установлении входящих соединений
`live_p2p_inbound_sybil_scenario.py`	Лимит входящих соединений на IP
`live_p2p_outbound_diversity_scenario.py`	Разнообразие сетевых групп исходящих пиров
`live_p2p_mesh_block_scenario.py`	Ретрансляция блока за пределы предпочтительного графа GossipSub

В начале каждого скрипта описаны переменные окружения и ожидаемые бинарники. Запускайте из корня репозитория:

python3 scripts/live_two_miner_fork_reorg_scenario.py

Изменения на границах

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

высоты 143, 144 и 145 для анкеров транзакций;
глубину ответвления 17 и 18 блоков;
разрыв синхронизации 18 и 19 блоков;
финализированные окна расширения с заполнением 9/9 и 10/8;
перезапуск с полным сохранённым окном расширения из 36 заголовков;
границы выплат и последнюю высоту периода распределения;
расширение State с одного уровня log_slots на следующий.

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