Agenda - Runtime Edge Test Plan

Problema

O core da VM está muito melhor testado do que a borda do runtime.

O miolo já cobre verificador, scheduler, GC, patching e execução básica. Já a camada de syscalls de sistema, FS, assets, bank e fluxos de firmware ainda tem cobertura desigual e rasa.

Dor

A parte mais sujeita a integração com host é justamente a menos protegida.
Regressões na borda podem passar com o core inteiro verde.
O projeto ganha falsa sensação de maturidade porque o núcleo está sólido, mas a superfície pública do runtime ainda pode quebrar com facilidade.
Sem matriz de testes da borda, futuras PRs tendem a cobrir só o happy path.

Alvo da Discussao

Definir um plano de testes para a borda do runtime proporcional ao risco da plataforma.

Essa agenda deve produzir uma visão clara de:

quais domínios precisam de testes;
qual nível de teste pertence a cada domínio;
quais cenários são mandatórios antes de chamar o runtime de estável.

O Que Precisa Ser Definido

Matriz de cobertura por domínio.
- system
- fs
- log
- asset
- bank
- firmware transitions
Tipos de teste.
- unitário puro
- integração entre runtime e VM
- testes de firmware
- testes host-dependentes isolados
Casos obrigatórios. Cada domínio precisa definir:
- happy path;
- erro de contrato do guest;
- indisponibilidade/estado inválido do host;
- persistência/cleanup de estado quando aplicável.
Critério de severidade. Que mudanças exigem teste novo obrigatório antes de merge.
Organização. Onde os testes vivem para nao voltar a concentrar tudo em arquivos gigantes.

O Que Necessita Para Resolver

inventário da cobertura atual;
definição dos cenários obrigatórios por domínio;
política mínima para testes ignorados ou dependentes de host;
decisão sobre helpers compartilhados para fixtures de runtime.

Fora de Escopo

benchmark/performance suite;
fuzzing completo de toda a ISA;
infraestrutura externa de CI além do necessário para os testes definidos.

Critério de Saida Desta Agenda

Pode virar PR quando houver:

matriz de cobertura aprovada;
lista de cenários mínimos por domínio;
decisão de organização dos testes;
barra clara para aceitar novas syscalls e mudanças de runtime.

2.3 KiB Raw Blame History