Test Taxonomy

mandatory

Catálogo completo das categorias de teste reconhecidas na Koder Stack — vocabulário fechado, com sinônimos da indústria, escopo, output dir e comando `/k-test-gen-*` correspondente. Ponto de partida para `k-test`, `k-test-run`, `k-test-doc` e `coverage-matrix.md`.

Toda categoria reconhecida pela Koder Stack tem:

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

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

  2. Sinô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. Escopo — o que entra (e o que NÃO entra) na categoria.
  4. Output convention — onde o teste vive na árvore do módulo,

    por linguagem.

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

    no runner.

Categorias fechadas — 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

Sinônimos: unit test, teste unitário, test de função, test de classe.

Escopo: 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.

Té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

Output:

  • 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

Comando: /k-test-gen-unit


2. functional

Sinônimos: functional test, teste funcional, capability test, "faz o que promete" test.

Escopo: 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.

Output:

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

Comando: /k-test-gen-func


3. integration

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

Escopo: 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.

Output:

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

Comando: /k-test-gen-integ


4. ui

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

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

Output:

  • 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

Comando: /k-test-gen-ui


5. flow

Sinônimos: end-to-end test (E2E), user journey test, user-flow test, navigation test, click-path test, system test.

Escopo: 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).

Output:

  • 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)

Marker: @requires-device na maioria dos casos.

Comando: /k-test-gen-flow


6. regression

Sinônimos: regression test, behavioral regression, golden regression, structural regression, confirmation test.

Escopo: 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.

Sub-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

Output:

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

    registry.

Comando: /k-test-gen-regress


7. performance

Sinônimos: performance benchmark, latency test, throughput test, microbenchmark, hot-path test.

Escopo: 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.

Output:

  • 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)

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


8. stress

Sinônimos: stress test, load test, spike test, volume test, scalability test, capacity test, "Black Friday" test.

Escopo: bombardeia o sistema com carga acima 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?".

Sub-formas (todas servidas pelo mesmo comando):

  • Load — carga esperada de produção; valida SLA
  • Stress — empurra alé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?

Output:

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

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

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

Comando: /k-test-gen-stress


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

Sinônimos: soak test, endurance test, durability test, longevity test, marathon test, 24h test.

Escopo: carga normal por horas 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 só aparecem após muitas horas de execução.

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

Output:

  • <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

Comando: /k-test-gen-soak


10. chaos (resilience / failover / DR)

Sinônimos: chaos engineering, chaos test, resilience test, failover test, disaster recovery test, fault injection.

Escopo: 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.

Sub-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

Output:

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

    falha + asserções de recuperação

Comando: /k-test-gen-chaos


11. security

Sinônimos: security test, pen test, penetration test, vulnerability scan, SAST, DAST, IAST.

Escopo: 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.

Sub-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 não entra aqui — é processo, não suite executada por /k-test-run.

Output:

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

    scanner.

Comando: /k-test-gen-sec


12. fuzz

Sinônimos: fuzzing, fuzz test, property-based test (parcial), mutation-input test.

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

Frameworks:

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

Output:

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

Comando: /k-test-gen-fuzz


13. mutation

Sinônimos: mutation testing, test-of-tests, mutation score.

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

Frameworks:

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

Output:

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

Comando: /k-test-gen-mutation


14. a11y (accessibility)

Sinônimos: accessibility test, a11y test, WCAG test, ARIA test, screen-reader test.

Escopo: 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.

Frameworks:

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

Output:

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

Comando: /k-test-gen-a11y


15. i18n (internationalization)

Sinônimos: i18n test, l10n test, localization test, pseudo-localization test.

Escopo: 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.

Técnicas:

  • Pseudo-localization — substitui strings por variantes

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

Output:

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

Comando: /k-test-gen-i18n


16. compat (compatibility)

Sinônimos: compatibility test, cross-browser test, cross-device test, cross-platform test, configuration test, backward/forward compat test, responsive test.

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

Sub-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

Output:

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

Comando: /k-test-gen-compat


17. smoke

Sinônimos: smoke test, sanity test, build verification test, "liga?" test.

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

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

Output:

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

Comando: /k-test-gen-smoke


18. api

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

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

Sub-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

Output:

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

    AssuredKaratenative)

  • `moduletestsapi/contracts