Test Coverage Matrix

mandatory

Matriz de aplicabilidade — quais categorias de teste fazem sentido para cada tipo de componente (`app/`, `backend/`, `engine/`, `cli/`, `landing/`, `tui/`, `tv/`, `sdk/`). Consultada por `/k-test` na Fase 2 para decidir quais geradores acionar por padrão.

Tipo de componente determina quais categorias /k-test aciona por padrão. ✅ = obrigatória; ◑ = recomendada (skip OK com justificativa em koder.toml [testing.skip]); — = não se aplica.

Categoria	`app/mobile`	`app/desktop`	`app/web`	`app/tv`	`app/cli`	`app/tui`	`backend/`	`engine/`	`landing/`	`sdk/`
unit	✅	✅	✅	✅	✅	✅	✅	✅	◑	✅
functional	✅	✅	✅	◑	✅	◑	✅	✅	◑	✅
integration	◑	◑	◑	—	◑	—	✅	◑	—	◑
ui	✅	✅	✅	✅	—	✅	—	—	✅	◑
flow	✅	✅	✅	✅	◑	◑	—	—	◑	—
regression	✅	✅	✅	✅	✅	✅	✅	✅	◑	✅
performance	◑	◑	◑	◑	◑	—	✅	✅	—	◑
stress	—	—	◑	—	—	—	✅	✅	—	—
soak	—	—	—	—	—	—	✅	✅	—	—
chaos	—	—	—	—	—	—	✅	◑	—	—
security	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
fuzz	◑	◑	◑	—	◑	—	✅	✅	—	◑
mutation	◑	◑	◑	—	◑	—	◑	◑	—	✅
a11y	✅	✅	✅	✅	—	—	—	—	✅	—
i18n	✅	✅	✅	✅	✅	◑	◑	—	✅	—
compat	✅	✅	✅	✅	◑	◑	◑	◑	✅	✅
smoke	✅	✅	✅	✅	✅	✅	✅	◑	✅	◑
api	—	—	—	—	—	—	✅	—	—	—
rules	◑	◑	◑	—	◑	—	✅	◑	—	—
install	✅	✅	—	✅	✅	✅	—	—	—	—
usability	✅	✅	✅	✅	◑	◑	—	—	✅	—
visual	✅	✅	✅	✅	—	◑	—	—	✅	◑
motion	◑	◑	◑	◑	—	—	—	◑	◑	—
audio	◑	◑	◑	◑	—	—	—	—	—	—
gesture	✅	◑	◑	—	—	—	—	—	◑	—
transcription	◑	◑	◑	—	◑	—	◑	◑	—	—

visual (incl. Categoria E scroll), motion, audio, gesture adicionadas 2026-06-07 (KSTACK-178179182183184). visual roda em toda surface visual (E = scroll-reachability; tui só a variante de largura de coluna). motion só onde há animação temporal (UIs animadas + engines de render como kvg/kompose). audio só onde toca som (vozmídiaevent-sounds → ◑). gesture só em surface touch: app/mobile ✅; desktopweb touch-capable ◑; `apptvé controle-remoto (D-pad), não touch →—. Skip via [testing.skip] reason="..."`.

Notas por dimensão

Por que `landing/` quase tudo é `◑`?

Landings são páginas estáticas (HTMLCSSJS). Têm pouca lógica para unit-testar, mas precisam de a11y, i18n, compat, smoke, ui (golden) e usability porque são a primeira impressão. Skip rules: marcar [testing.skip] reason="static landing" para unitfunctionalintegration.

Por que `engine/` recebe `chaos` como `◑`?

Engines são embarcáveis (importadas + executadas em-processo). Falhas externas (rede caindo) raramente importam, mas falhas internas — OOM no host, GC pause, FD exhaustion — sim. O modo chaos do engine tipicamente injeta panic/raise em pontos estratégicos para verificar cleanup.

Por que `cli/` recebe `flow` como `◑`?

CLIs têm fluxos (login → search → install). Mas o "browser headless" da CLI é o terminal — testes ficam mais próximos de E2E shell que de browser-driver. tests/e2e/cli_*.sh é o lugar canônico.

Por que `backend/` não recebe `ui``a11y``flow`/`usability`?

Backend é consumido via API. A11y/usability se aplicam a /landing e ao admin dashboard quando este existir como UI separada. Backend recebe api como ✅ — esse é o equivalente estrutural.

Por que `sdk/` recebe `mutation` como ✅?

SDKs são consumidos por dezenas de módulos. Um bug não pego pelos testes do SDK propaga em escala. Mutation score ≥ 80 % é obrigatório para qualquer SDK (gate em /k-housekeep).

Por que `tv/` raramente recebe `integration`/`flow`?

TV apps (Tizen / WebOS) têm ferramental de teste primitivo. UI golden + smoke + i18n + a11y dão cobertura razoável; integração real precisa do device físico (caso de flow em ◑).

Como `/k-test` consulta esta matriz

/k-test <module>
  → lê <module>/koder.toml para descobrir o `kind` (app/backend/...)
  → consulta esta matriz para o `kind`
  → aciona apenas as categorias ✅ + ◑ (a menos que o módulo opte
    por skip via [testing.skip] = ["soak", "chaos"])
  → respeita --category <cat> para modo cirúrgico, ignorando a
    matriz

Override por módulo

Em <module>/koder.toml:

[testing]
# Adicionar categoria não-default (ex.: cli rodando soak):
extra = ["soak"]

# Pular categoria default com justificativa:
skip = [
  "compat",  # tem que ser justificada em texto livre abaixo
]

[testing.justification]
compat = "Componente shipped só para Linux x86_64; cross-platform N/A"

Auditoria

/k-housekeep Fase X audita cada módulo:

Lê kind em koder.toml.
Compara categorias presentes em tests/ com a matriz.
Para cada ✅ ausente sem [testing.skip] justificado, abre
ticket <module>/backlog/pending/NNN-add-<cat>-tests.md.
Para cada ◑ ausente, anota WARN (não abre ticket
automaticamente).

A matriz aqui é a fonte da verdade — qualquer descumprimento exige RFC ou skip justificado.

Notas por dimensão

Por que landing/ quase tudo é ◑?

Por que engine/ recebe chaos como ◑?

Por que cli/ recebe flow como ◑?

Por que backend/ não recebe uia11yflow/usability?

Por que sdk/ recebe mutation como ✅?

Por que tv/ raramente recebe integration/flow?

Como /k-test consulta esta matriz