Spec: Test Taxonomy — categorias canônicas

Toda categoria reconhecida pela Koder Stack tem:

1. *lug canônico*— nome curto usado em koder.toml [testing],

   nos diretórios de output e nos comandos /k-test-gen-<slug>.

2. *inônimos da indústria*— termos equivalentes que aparecem em

   docs, revisões e onboarding. Os comandos /k-test-gen-* aceitam qualquer um deles via alias.

3. *scopo*— o que entra (e o que NÃO entra) na categoria.
4. *utput convention*— onde o teste vive na árvore do módulo,

   por linguagem.

5. *omando*— /k-test-gen-<slug> (gera) e o filtro equivalente

   no runner.

Categorias *echadas*— qualquer cenário cabe em uma das 21 abaixo ou é uma combinação delas. Adicionar uma 22ª exige RFC que actualiza este documento, coverage-matrix.md e commands/k-test.md.

---

1. unit

*inônimos* unit test, teste unitário, test de função, test de classe.

*scopo* função ou classe isoladas, todas as dependências substituídas por fakes/mocks. Execução em ms, milhares por suíte. Sem rede, sem disco fora de tmpfs, sem clock real.

*écnicas que entram aqui*(não são categorias separadas):

• Equivalence partitioning — particiona domínio de entrada
• Boundary value analysis — valores nas fronteiras (min, max, ±1)
• Cause-effect graph — mapeia condições para efeitos
• Property-based testing (QuickCheck/Hypothesis) — define

  invariantes, framework gera entradas

*utput*

• Go: co-located *_test.go com func TestXxx(t *testing.T)
• Dart: <module>/test/<symbol>_test.dart
• Rust: #[cfg(test) mod tests em-arquivo + crate/tests/ para integração
• TypeScript: <symbol>.test.ts ao lado do <symbol>.ts
• KL: tests/<symbol>_test.kd

*omando* /k-test-gen-unit

---

2. functional

*inônimos* functional test, teste funcional, capability test, "faz o que promete" test.

*scopo* feature inteira observada de fora, sem cair no nível unit. Diferente do E2E porque exercita apenas uma capacidade específica (ex.: "submeter formulário grava no DB"), não um fluxo multi-tela.

*utput*

• <module>/tests/functional/<feature>_test.<ext>

*omando* /k-test-gen-func

---

3. integration

*inônimos* integration test, teste de integração, in-process integration.

*scopo* dois ou mais componentes reais cooperando dentro do mesmo processo (ex.: handler HTTP + DB real + cache). Diferente do E2E porque não atravessa a UI ou processos remotos.

*utput*

• <module>/tests/integration/<feature>_test.<ext>
• Go: pode ficar co-located com tag // +build integration

*omando* /k-test-gen-integ

---

4. ui

*inônimos* widget test (Flutter), component test (React), golden test, snapshot test, visual regression test, screenshot diff, golden master.

*scopo* renderiza um componente isolado e verifica a árvore resultante e/ou compara contra uma imagem baseline. Cobre layout, interação local, estados visuais.

*utput*

• Flutter: <module>/test/scenarios/<widget>_test.dart ou

  <module>/test/widget/<widget>_test.dart; goldens em <module>/test/goldens/

• ReactTS: <symbol>.test.tsx + `_napshots_`
• Web (Storybook): *.stories.ts + Chromatic/Percy diff

*omando* /k-test-gen-ui

---

5. flow

*inônimos* endtoend test (E2E), user journey test, user-flow test, navigation test, click-path test, system test.

*scopo* percorre o produto pelo caminho de um usuário real — login → busca → compra → checkout — atravessando todas as camadas (UI, API, DB) e potencialmente múltiplos processos. Pode rodar em emulador (mobile), browser headless (web), ou desktop window (LinuxmacOSWindows).

*utput*

• Flutter: <module>/integration_test/<flow>_test.dart
• Web: <module>/tests/e2e/<flow>.spec.ts (Playwright/Cypress)
• Cross-process: <module>/tests/e2e/<flow>.sh (shell + ADB/curl)

*arker* @requires-device na maioria dos casos.

*omando* /k-test-gen-flow

---

6. regression

*inônimos* regression test, behavioral regression, golden regression, structural regression, confirmation test.

*scopo* lock contra retorno de bug já corrigido. Cresce monotonicamente com o tempo. Cada caso tem um número sequencial e é registrado em meta/context/registries/regression-test-cases.md.

*ub-tipos*(todos com o mesmo comando):

• Behavioral — reproduz a ação que disparava o bug
• Golden — compara saída atual com baseline pré-correção
• Estrutural — verifica que código permanece numa forma específica

*utput*

• <module>/tests/regression/NNN-<bug-slug>_test.<ext>
• Numeração: 3 dígitos zero-padded; NNN é o próximo livre no

  registry.

*omando* /k-test-gen-regress

---

7. performance

*inônimos* performance benchmark, latency test, throughput test, microbenchmark, hot-path test.

*scopo* mede tempo / throughput / alocações de um símbolo único. Determinístico (RNG seedado, sem rede) — diferenças entre runs são sinal, não ruído. Cada run produz um número comparável que entra em histórico.

*utput*

• Go: *_bench_test.go com func BenchmarkXxx(b *testing.B)
• Dart: <module>/test/benchmark/perf/<symbol>_bench_test.dart

  (package:benchmark_harness)

• Rust: <module>/benches/<symbol>.rs (criterion)
• TypeScript: <module>/__tests__/benchmark/<symbol>.bench.ts

  (tinybench / vitest bench)

*omando* /k-test-gen-perf · também /k-bench para comparação cross-baseline.

---

8. stress

*inônimos* stress test, load test, spike test, volume test, scalability test, capacity test, "Black Friday" test.

*scopo* bombardeia o sistema com carga *cima do esperado*para encontrar o ponto de quebra. Diferente de performance porque a métrica de interesse é "quando deixa de funcionar?" e não "quão rápido?".

*ub-formas*(todas servidas pelo mesmo comando):

• Load — carga *sperada*de produção; valida SLA
• Stress — empurra *lém*do esperado; encontra ponto de quebra
• Spike — picos súbitos de tráfego (viralização, Black Friday)
• Volume — datasets gigantes (10M registros, arquivos de 50GB)
• Scalability — métricas evoluem como ao escalar 1x→10x→100x?
• Capacity — quantos usuários simultâneos com SLA X?

*utput*

• <module>/tests/benchmark/stress/<scenario>.{toml,yaml,sh} —

  cenário + harness (k6, vegeta, locust)

• Resultados em docs/tests/benchmarks/stress.md

*omando* /k-test-gen-stress

---

9. soak (durability / endurance / longevity / reliability)

*inônimos* soak test, endurance test, durability test, longevity test, marathon test, 24h test.

*scopo* carga *ormal*por *oras ou dias*(12h+ típico). Caça vazamentos de memória, fragmentação de heap, deadlocks acumulativos, drift de relógio, exhaustion de file descriptors, acumulação de GC pause times — coisas que *ó aparecem após muitas horas de execução*

*ergunta a responder* "se eu deixar isso rodando 24h sob carga normal, o quê deteriora?"

*utput*

• <module>/tests/benchmark/soak/<scenario>.{toml,yaml,sh}
• Resultados em docs/tests/benchmarks/soak.md com gráfico de

  RSS / latência p99 / GC pause ao longo do tempo

*omando* /k-test-gen-soak

---

10. chaos (resilience / failover / DR)

*inônimos* chaos engineering, chaos test, resilience test, failover test, disaster recovery test, fault injection.

*scopo* injeta falhas (rede caindo, instância morrendo, DB indisponível, latência adicionada) e verifica que o sistema recupera automaticamente, dentro do RTO/RPO esperado.

*ub-formas*

• Chaos — falhas aleatórias estilo Netflix Simian Army
• Failover — ativa o standby; mede tempo + correção
• Disaster recovery — restaura backup em ambiente novo;

  mede RTO/RPO

*utput*

• <module>/tests/chaos/<scenario>.{sh,yaml} — descritor de

  falha + asserções de recuperação

*omando* /k-test-gen-chaos

---

11. security

*inônimos* security test, pen test, penetration test, vulnerability scan, SAST, DAST, IAST.

*scopo* verificações de segurança — credentials hardcoded, endpoints sem auth, SQL injection, XSS, CSRF, CORS overly- permissive, headers ausentes (CSP, HSTS), dependências com CVE.

*ub-tipos*(todos servidos pelo comando):

• SAST — análise estática (Semgrep, CodeQL)
• DAST — runtime probing (OWASP ZAP, Burp)
• IAST — instrumentação + tráfego de teste
• SCA — software composition (Snyk, Dependabot, govulncheck)

Pen-test manual / red team *ão*entra aqui — é processo, não suite executada por /k-test-run.

*utput*

• <module>/tests/security/<rule>_test.<ext> ou config de

  scanner.

*omando* /k-test-gen-sec

---

12. fuzz

*inônimos* fuzzing, fuzz test, property-based test (parcial), mutation-input test.

*scopo* alimenta o sistema com *nputs aleatórios ou mutados*procurando crashes, panics, hangs, OOMs, memory corruption. Diferente de unit/property-based porque o objetivo é "quebrar" não "validar invariantes".

*rameworks*

• Go: go test -fuzz (nativo desde 1.18)
• Rust: cargo-fuzz (libFuzzer)
• C/C++: AFL, libFuzzer
• TS/JS: jsfuzz, fastcheck (mais propertybased)

*utput*

• Go: *_fuzz_test.go com func FuzzXxx(f *testing.F)
• Rust: <crate>/fuzz/fuzz_targets/<target>.rs

*omando* /k-test-gen-fuzz

---

13. mutation

*inônimos* mutation testing, testoftests, mutation score.

*scopo* introduz mutações no *ódigo sob teste*(troca > por >=, + por -, removes returns) e verifica se a suíte detecta. Mede a *ualidade dos testes* não o código. Score = mutações detectadas / total injetadas.

*rameworks*

• Go: gremlins, go-mutesting
• Dart: mutation_test
• TS: stryker
• Java: pitest

*utput*

• Configuração em <module>/mutation.toml
• Relatório em docs/tests/mutation/<module>.md

*omando* /k-test-gen-mutation

---

14. a11y (accessibility)

*inônimos* accessibility test, a11y test, WCAG test, ARIA test, screen-reader test.

*scopo* conformance com WCAG 2.1 AA — contraste, foco visível, alt text, ordem de tab, anúncios de live regions, labels associadas a inputs, touch targets ≥ 44pt.

*rameworks*

• Web: axe-core, Lighthouse, Pa11y
• Flutter: package:flutter_test semantics matchers
• iOS: XCUIAccessibility
• Android: Espresso AccessibilityChecks

*utput*

• <module>/tests/a11y/<screen>_test.<ext>

*omando* /k-test-gen-a11y

---

15. i18n (internationalization)

*inônimos* i18n test, l10n test, localization test, pseudo-localization test.

*scopo* render correto em múltiplos locales — texto expandindo (~30% para alemão), RTL (árabe/hebraico), encoding, plurais, datasnúmerosmoedas formatadas, fallback de locale não suportado.

*écnicas*

• Pseudo-localization — substitui strings por variantes

  acentuadas/longas para flagrar UI quebrada antes de tradução real

*utput*

• <module>/tests/i18n/<scenario>_test.<ext>

*omando* /k-test-gen-i18n

---

16. compat (compatibility)

*inônimos* compatibility test, cross-browser test, crossdevice test, crossplatform test, configuration test, backward/forward compat test, responsive test.

*scopo* mesma funcionalidade em N ambientes — múltiplas versões de browser, OS, viewport, configurações de feature flags, locale do sistema.

*ub-tipos*

• Cross-browser — Chrome / Firefox / Safari / Edge
• Cross-device — viewports / touch / OSes
• Responsive — breakpoints (mobile / tablet / desktop)
• Backward compat — versão nova lê dados antigos
• Forward compat — versão antiga ignora campos novos

*utput*

• <module>/tests/compat/<env>/<scenario>_test.<ext>

*omando* /k-test-gen-compat

---

17. smoke

*inônimos* smoke test, sanity test, build verification test, "liga?" test.

*scopo* subset mínimo que valida o build mais elementar. Roda primeiro no pipeline. Falha → bloqueia tudo. Tipicamente < 30 s wall clock.

*iferença para sanity* smoke é abrangente-raso (toca todas as áreas críticas superficialmente); sanity é estreito-fundo (uma área específica após mudança).

*utput*

• <module>/tests/smoke/smoke_test.<ext>

*omando* /k-test-gen-smoke

---

18. api

*inônimos* API test, contract test, schema test, REST/gRPC test, consumer-driven contract (CDC).

*scopo* chama endpoints HTTPgRPCGraphQL e valida response contra spec (OpenAPI / Protobuf / GraphQL schema). Diferente de integration porque foca *o contrato*entre serviços, não na correção interna.

*ub-tipos*

• Schema test — response valida contra OpenAPI/JSON Schema
• Contract test (CDC) — Pact-style; consumidor define o

  contrato, provedor valida

• Smoke API — pinga endpoints críticos pós-deploy

*utput*

• <module>/tests/api/<endpoint>_test.<ext> (Postman/REST

  AssuredKaratenative)

• `moduletestsapi/contracts